On my machine #echo 'hello' in my makefile prints out 'hello'. Yet on another machine it prints out hello without the quotes.
So #echo 'hello' is incorrect on my machine but correct on my colleges.
Yet #echo hello works fine on my machine.
This is not just limited to echo, it seems that my machine does not work with quotes yet my colleges does. We have similar machines and are using the same version of make.
This is a problem as we are both trying to use the same makefile, yet I cannot process the file correctly?
Related
I am using Ubuntu via WSL 2.0 on Windows 10 and would like to run Texlive from the Windows command line. To do so I prepended the Texlive folder to the path in /etc/environment (I also tried a number of other locations eg. $HOME/.bashrc):
C:\Users\scott\Documents>wsl echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
C:\Users\scott\Documents>wsl
scott#SCOTT-PC:/mnt/c/Users/scott/Documents$ echo $PATH
/usr/local/texlive/2020/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
Why is there a difference between these two paths? Is it possible to change the first PATH variable?
To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.
Let's start with the fairly "easy" part, though. The main difference between the first method and the second:
wsl by itself launches into a login (and interactive) shell
the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell
So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.
You can see this a different way (and get to the solution) with the following commands:
wsl -e bash -c 'echo $PATH'
wsl -e bash -li -c 'echo $PATH'
The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as #bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.
You should be able to run TeX Live the same way, just replacing the "echo $PATH" with the startup command you need for TeX Live.
A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh
That said, I honestly don't think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that's to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there's no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.
I'd expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that's where the shell is picking it up from at the moment.
While this isn't necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn't used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don't have that feature disabled in /etc/wsl.conf).
I'm running ubuntu 1804 on windows using the WSL. Everything is set up fine and works correctly. I've also installed ZSH and oh-my-zsh, again this is all good and everything looks like its working fine. Everything except the arrow keys whilst using vim or man pages or some other command line tools.
The up and down keys work on the command line when scrolling through history and also for select commands like nano. Also if I boot into bash rather than zsh the arrow keys do work in vim and man pages, in fact they work everywhere.
If i boot into bash, then switch to zsh on the command line manually the arrow keys then work everywhere.
So my cmder config for zsh
c:/_distros/ubuntu1804/ubuntu1804.exe -c zsh -cur_console:pm
and for bash
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pm:/mnt
The one for bash uses the conemu-cyg-64.exe program that comes from conemu which is a symbiont of POSIX enabled pty and WinAPI full-featured terminal.
Apparently you can use this tool with zsh but i cant manage to make it work i get the error
{PID:10592} failed to run shell (2): No such file or directory
{PID:10592} shell: `/usr/bin/zsh` `-l` `-i`
{PID:10592} dir: `/cygdrive/c/Program Files/cmder`
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
and this is the task in cmder
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe /usr/bin/zsh -l -i -cur_console:pm:/mnt
So I think that if i can boot into zsh using conemu-cyg-64 that the cursor keys will probably work in commands like vim and the man pages. Any help or advice getting that working would be brilliant.
EDIT:
On my ubuntu install zsh is installed at /usr/bin/zsh, but there is no file or folder /cygdrive/c/Program Files/cmder
Many thanks to #Maximus for pointing me in the right direction. The answer was right under my nose at the bash on windows page of conemu. A small change to the command i was using before. the zsh needs to go on the end rather than before the --wsl.
The correct task to ensure that cursor keys work on all apps in the terminal is:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -t zsh -l
I have an executable file test, it contains
a="$RANDOM"
echo "$a">>out
Now, if I simply ./test then out contains a random number. But if I nohup ./test & then out is empty. Why?
Transferring comment into an answer
Are you on Ubuntu (or another Linux distro)? Is /bin/sh a link to /bin/dash rather than /bin/bash? If so, when you run it with bash as your shell, then $RANDOM works, but when nohup runs it with /bin/sh (aka dash), you get nothing.
You might be able to fix it by using #!/bin/bash as the shebang line.
Actually I'm on Debian. But anyway I forgot the shebang indeed; now it works perfectly.
Great!
Incidentally, however tempting it is, it's generally a bad idea to call programs test because there is a shell built-in called test (also known as [) that can readily cause confusion if it is run instead of your test program.
I am executing a ksh script named abs.ksh located at /app/fao.... which connects to a server,
But the server is receiving a script named "ksh" which is present in /usr/bin...
I am not calling any script called ksh in abs.ksh(sorry cannot paste the code).
Also this happens only when the script is run in debug mode.
In non debug mode it works fine.
Can anyone give me a hint of what might be happening here.
In a standard "classic" Unix environment there may be multiple shells. E.g. 'sh' the original Bourne shell, 'ksh' - the Korn shell, csh - the C shell, bash, tcsh etc. etc.. A user login will have the default shell set per login.
The #! at the start of an executable script is an instruction to interpret & run the subsequent text with the name of the program following the '#!'.
E.g. run this with perl
#!/bin/perl
<.. perl stuff ..>
So yes #!/usr/bin/ksh - will run the script with the command interpreter (shell) at that location.
Need more info. wrt how you run in debug mode. I.e. are you typing 'ksh -x ...' or 'sh -x' - if so where is that on your search path. E.g. 'whence ksh' - maybe you're running with a different shell in debug mode.
Also which os is this ?
as an replacement for ksh under cygwin, pdksh might be the only choice. but look like there have a bug for cygwin : pdksh(5.2.14-3) to support backslash path (\).
it will swallow the \ :
$ cd .\access
pdksh: cd: /cygdrive/e/.access - No such file or directory
After search on the internet, the same problem solved for other platform. but no idea how to solve it for cygwin.
Pdksh, like all Cygwin programs, does support backslashes as directory separators. But you have to quote them properly. Running shell scripts under Cygwin really teaches you to quote things properly, in particular to always put variable substitutions in double quotes, and not use echo carelessly (printf "%s" "$x" is portable and reliable: unlike echo, there's no risk that it might do backslash expansion).
Note that pdksh's compatibility with even ksh88 is far from perfect, so some scripts may fail for other reasons (such as relying on the status code of writer | reader being that of reader, which is the case in true ksh but not in pdksh). Cygwin includes zsh, which after you run emulate ksh is mostly compatible with ksh88 (though still not perfect).
There are non-Cygwin ports of ksh for Windows, including InterixSFUSUA and ATT's own port.
You have to use forward slashes, or double all the backslashes, or single-quote every string that might be a pathname. Sorry, there's no way around this. This is a general problem with trying to use Unix shells, for which \ is an escape character, on Windows.
From the Cygwin User's Guide:
Note
The usage of Win32 paths, though possible, is deprecated, since it circumvents important internal path handling mechanisms. See the section called “Using native Win32 paths” and the section called “Using the Win32 file API in Cygwin applications” for more information.
There is a utility called cygpath that is designed to be used in shell scripts that converts each way between Win32 and POSIX paths.
Here's a workaround for the problem. Start using bash and make the following modifications in config files.
Open ~/.bashrc
Add the following code at the end
wcd()
{
cd $(echo "$#" | sed 's/\\/\\\\/g')
}
Save it
Reload bash terminal.
Type
wcd ".\access"
along with the quotes and voila, you have your own windows compatible cd command.