I have a simple shell function to convert a *nix style path to Windows style (I happen to be using Windows Subsystem for Linux).
# convert "/mnt/c/Users/josh" to "C:\Users\josh"
function winpath(){
enteredPath=$1
newPath="${enteredPath/\/mnt\/c/C:}" # replace /mount/c/ with C:
newPath="${newPath//\//\\}" # replace / with \
echo $newPath
}
The desired behavior is:
$ winpath /mnt/c/Users/josh
C:\Users\josh
This works correctly in bash, but in zsh, echo seems to do some extra interpolation of the $newPath value. It behaves like this:
$ winpath /mnt/c/Users/josh
C:sers\josh
What character sequence is echo interpolating and why is it remove the \U? Most importantly, how do I return the literal value?
I've tried digging through the zsh documentation, but it's a jungle. Thanks in advance!
zsh processes certain escape sequences that bash does not by default. \U introduces 4-byte Unicode codepoint, but since the following 8 characters are not a valid hexadecimal number, no character is substituted.
I would recommend using printf, as its behavior is much more predictable from shell to shell.
printf '%s\n' "$newPath"
The problem is that you are using the internal command echo, instead of the external one. If you would write
command echo $newPath
you would get the expected output. command forces zsh to look up the command word according to the current PATH, ignoring internal commands, aliases or functions of the same name.
Related
I added the following function to my .zshrc
function jptt(){
# Forwards port $1 into port $2 and listens to it
ssh -N -f -L localhost:$2:localhost:$1 remoteuser#remotehost
}
then I am running jptt 1 2
and get the following error:
Bad local forwarding specification localhost:2ocalhost:1
It is strange that I lose :l after the 2
the function is working when as I tried to replace the command with a simple line and it worked. I also run the ssh command separately and it works well.
The expression $x:l applies the lower-casing modifier to your x variable. The following example illustrates this:
pax> x=ABC
pax> echo $x:lnnn
abcnnn
pax> echo ${x}:lnnn
ABC:lnnn
The first section gives you the lower-case variant, and therefore the modifier is not considered part of your output string. The second section shows how you can prevent this variable expansion by using braces to ensure the :l is not treated as a modifier. In your specific case, that would be done with the line:
ssh -N -f -L localhost:${2}:localhost:${1} remoteuser#remotehost
It's actually a good idea to get into the habit of bracing parameter names as much as possible since there are other cases where this might adversely affect you.
Use ${1} and ${2} . Zsh supports : csh string modificators and :l has special meaning (to lowercase variable in front of it) and that's why it is consumed from $1:localhost.
How can I use =(list)-style process substitution in the middle of an argument?
This works:
% echo =(echo)
/tmp/zshxxxxxx
So does this:
% echo =(echo):works
/tmp/zshxxxxxx:works
But this does not:
% echo broken:=(echo)
zsh: missing end of string
Notably, this also works:
% echo works:<(echo)
works:/proc/self/fd/11
The problem is =(list) can only stand at the beginning of arguments. Quoting from the ZSH manual:
The expression may be preceded or followed by other strings except
that, to prevent clashes with commonly occurring strings and patterns,
the last form [this is =(list)] must occur at the start of a command
argument, and the forms are only expanded when first parsing command
or assignment arguments.
I have a tool that accepts an argument of the form format:filename, and I need to use a real file, not a pipe, so I cannot use <(list). What is a reasonably simple and readable solution?
Use parameter expansion to "buffer" the process substitution.
% echo fixed:${:-=(echo)}
fixed:/tmp/zshxxxxxx
I have been trying to use the previous answer for a makefile, and it was not so trivial so here is my solution.
The initial problem is that with MinGW, the command line length is quite limited and it will get truncated in case of a very long object list, so I need to use the #file syntax for gcc, which allow to provide the arguments in a file.
SHELL := /bin/zsh
myprog.exe: very.o long.o list.o of.o obj.o files.o ...
gcc -o $# #$${:-=(<<< \"$^\")}
There is an alternate solution by using an anonymous function called immediatly :
myprog.exe: very.o long.o list.o of.o obj.o files.o ...
() { gcc -o $# #$$1 } =(<<< "$^")
Using this UNIX script I am able to check if variable TEST_VAR is set or not:
: ${TEST_VAR:?"Not set or empty."}
I am new to unix so can someone please explain what is this command.
From bash manual:
${parameter:?word}
If parameter is null or unset, the expansion of word (or a message to
that effect if word is not present) is written to the standard error
and the shell, if it is not interactive, exits. Otherwise, the value
of parameter is substituted.
It is the original shell comment notation (before '#' to end of line). For a long time, Bourne shell scripts had a colon as the first character. The C Shell would read a script and use the first character to determine whether it was for the C Shell (a '#' hash) or the Bourne shell (a ':' colon). Then the kernel got in on the act and added support for '#!/path/to/program' and the Bourne shell got '#' comments, and the colon convention went by the wayside
Have a look at this similar question:
What's a concise way to check that environment variables are set in a Unix shell script?
The following statement work at command prompt. But does not work in a cron.
myvar=`date +'%d%m'`; echo $myvar >> append.txt
The cron log shows that only a part of the date statement is run.
How do I use it in a cron?
Escape the percent signs with a backslash (\%).
My general rule of thumb is "do not write scripts in the crontab file". That means I don't place anything other than a simple script name (with absolute path) and possibly some control arguments in the crontab file. In particular, I do not place I/O redirection or variable evaluations in the crontab file; such things go in a (shell) script run by the cron job.
This avoids the trouble - and works across a wide variety of variants of cron, both ancient and modern.
from man 5 crontab:
The sixth field (the rest of the
line) specifies the command to be run.
The entire command portion of the line, up to a newline or % character, will be
executed by /bin/sh or by
the shell specified in the SHELL variable of the cronfile.
Percent-signs (%) in the command, unless escaped with backslash (), will be changed into
newline characters, and all
data after the first % will be sent to the command as standard input.
Your %s are being changed to newlines, and the latter part of your command is being fed to the command as stdin. As Ignacio says, you need to escape the %s with a \
How does unix handle full path name with space and arguments ?
In windows we quote the path and add the command-line arguments after, how is it in unix?
"c:\foo folder with space\foo.exe" -help
update:
I meant how do I recognize a path from the command line arguments.
You can either quote it like your Windows example above, or escape the spaces with backslashes:
"/foo folder with space/foo" --help
/foo\ folder\ with\ space/foo --help
You can quote if you like, or you can escape the spaces with a preceding \, but most UNIX paths (Mac OS X aside) don't have spaces in them.
/Applications/Image\ Capture.app/Contents/MacOS/Image\ Capture
"/Applications/Image Capture.app/Contents/MacOS/Image Capture"
/Applications/"Image Capture.app"/Contents/MacOS/"Image Capture"
All refer to the same executable under Mac OS X.
I'm not sure what you mean about recognizing a path - if any of the above paths are passed as a parameter to a program the shell will put the entire string in one variable - you don't have to parse multiple arguments to get the entire path.
Since spaces are used to separate command line arguments, they have to be escaped from the shell. This can be done with either a backslash () or quotes:
"/path/with/spaces in it/to/a/file"
somecommand -spaced\ option
somecommand "-spaced option"
somecommand '-spaced option'
This is assuming you're running from a shell. If you're writing code, you can usually pass the arguments directly, avoiding the problem:
Example in perl. Instead of doing:
print("code sample");system("somecommand -spaced option");
you can do
print("code sample");system("somecommand", "-spaced option");
Since when you pass the system() call a list, it doesn't break arguments on spaces like it does with a single argument call.
Also be careful with double-quotes -- on the Unix shell this expands variables. Some are obvious (like $foo and \t) but some are not (like !foo).
For safety, use single-quotes!
You can quote the entire path as in windows or you can escape the spaces like in:
/foo\ folder\ with\ space/foo.sh -help
Both ways will work!
I would also like to point out that in case you are using command line arguments as part of a shell script (.sh file), then within the script, you would need to enclose the argument in quotes. So if your command looks like
>scriptName.sh arg1 arg2
And arg1 is your path that has spaces, then within the shell script, you would need to refer to it as "$arg1" instead of $arg1
Here are the details
If the normal ways don't work, trying substituting spaces with %20.
This worked for me when dealing with SSH and other domain-style commands like auto_smb.