Is there a way to get *actual* (uninterpreted) shell arguments in a function or script?

Question

I have a function posix that I use in the Git bash shell on Windows to transform DOS-style paths to normal Unix-style paths. Since DOS-style paths use a backslash as separator, I have to quote the path argument to prevent the backslashes as being used by the shell to denote the next character as a literal. Is there any way to get the uninterpreted argument from inside my function, so that I don't need to quote it?

Here is my function, if it helps:

function posix() {
  echo $1 | sed -e 's|\\|/|g' | sed -re 's|^(.)\:|/\L\1|'
}

_{(By the way, I welcome any comments with tips for improving the function in other ways unrelated to solving the quoting/shell-interpretation problem.)}

Answer 1

The uninterpreted shell arguments are $1, $2, etc. You need to put their expansion in double quotes in most contexts, to avoid the value of the parameter being expanded further. "$@" gives you the list of all parameters.

For example, if you want to pass an argument of the shell script to your function, call it like this:

first_argument_as_filename_in_unix_syntax=$(posix "$1")

The double quotes are necessary. If you write posix $1, then what you're passing is not the value of the first parameter but the result of performing word splitting and globbing on the value of the first parameter. You will need to use proper quoting when calling the script, too. For example, if you write this in bash:

myscript c:\path with spaces\somefile

then the actual, uninterpreted arguments to myscript will be c:path, with and spacessomefile. So don't do this.

Your posix function is wrong, again because it lacks double quotes around $1. Always put double quotes around variable and command substitutions: "$foo", "$(foo)". It's easier to remember this rule than the exceptions where you don't actually need the quotes.

echo does its own processing in some cases, and calling external processes is slow (especially on Windows). You can do the whole processing inside bash.

posix () {
  path="${1//\\//}"
  case "$path" in
    ?:*) drive="${p:0:1}"; drive="${drive,}"; p="/$drive/${p:2}";;
  esac
  printf %s "$p"
}

---

_{The zsh feature that jw013 alluded to doesn't do what you seem to think it does. You can put noglob in front of a command, and zsh does not perform globbing (i.e. filename generation, i.e. expansion of wildcards) on the arguments. For example, in zsh, if you write noglob locate *foo*bar*, then locate is called with the argument *foo*bar*. You'd typically hide the noglob builtin behind an alias. This feature is irrelevant for what you're trying to do.}

Answer 2

While other answers may be correct in stating that you cannot receive "uninterpreted" shell input via the means they mention, they are wrong in categorically denying it as a possibility. You can certainly receive it before the shell interprets it if you instruct the shell not to interpret it. The humble POSIX heredoc makes this very simply possible:

% sed -e 's@\\@/@g' -e 's@\(.\):\(.*\)@/drive/\1\2@' <<'_EOF_'     
> c:\some\stupid\windows\place
> _EOF_
/drive/c/some/stupid/windows/place

EDIT1:

In order to pass such a string to a shell function as a shell argument you're going to need to store it in a shell variable. Generally you cannot simply var=<<'HEREDOC' unfortunately, but POSIX does specify the -r argument to the read builtin:

% man read

POSIX PROGRAMMER'S MANUAL

...

By default, unless the -r option is specified, backslash ( '\' ) shall act as an escape character, as described in Escape Character (Backslash) . If standard input is a terminal device and the invoking shell is interactive, read shall prompt for a continuation line when:

• The shell reads an input line ending with a backslash, unless the -r option is specified.

• A here-document is not terminated after a new line is entered.

When combined, read and the heredoc make this a trivial and portable matter as well, though it may not feel very intuitive at first:

% _stupid_mspath_fix() { 
> sed -e 's@\\@/@g' -e 's@\(.\):\(.*\)@/drive/\1\2@' <<_EOF_
>> ${1}
>> _EOF_
> }
% read -r _stupid_mspath_arg <<'_EOF_'                    
> c:\some\stupid\windows\place
> _EOF_
% _stupid_mspath_fix ${_stupid_mspath_arg}
/drive/c/some/stupid/windows/place

EDIT2:

Probably you noticed the difference between the two heredocs in the second example. The heredoc _EOF_ terminator within the function is unquoted, while the one fed to read is quoted with single quotes. In this way the shell is instructed to perform expansion on the heredoc with an unquoted terminator, but not to do so when its terminator is quoted. It doesn't break when expanding the unquoted heredoc in the function because the value of the variable it expands is already set as a quoted string and it doesn't parse it twice.

Probably what you want to do involves piping your Windows path from the output of one command into the input of another dynamically. Command substitution within a heredoc makes this possible:

% _stupid_mspath_fix() { 
> sed -e 's@\\@/@g' -e 's@\(.\):\(.*\)@/drive/\1\2@' <<_EOF_
>> ${1}
>> _EOF_
> }
% read -r _stupid_mspath_arg <<'_EOF_'                    
> c:\some\stupid\windows\place
> _EOF_
% _stupid_mspath_fix ${_stupid_mspath_arg}
/drive/c/some/stupid/windows/place    
% read -r _second_stupid_mspath_arg <<_EOF_                    
> $(printf ${_stupid_mspath_arg})
> _EOF_
% _stupid_mspath_fix ${_second_stupid_mspath_arg}
/drive/c/some/stupid/windows/place

So basically if you can reliably output the backslashes from some application (I used printf above), then running that command within $(...) and enclosing that within an unquoted heredoc passed to another application that can reliably accept the backslashes as input (such as read and sed above) will bypass the shell's parsing of your backslashes altogether. Whether or not the applications can handle the backslashes as input/output is something you'll have to find out for yourself.

Not strictly relevant to the question:

In Gilles's answer he recommends the ${var/search/replace} parameter expansion form, which, though cool, is not POSIX. It is definitely a bashism. It wouldn't matter to me, but in his edits he retained the posix () function name, and that may be misleading to some.

On that note, the original post's posix () function makes use of the very convenient extended regex sed -r argument, but that is also, unfortunately, not POSIX. POSIX does not specify an extended regex argument for sed, and its use is therefore possibly unreliable.

My account at stack overflow is only a few only days old as well, but I've posted a few answers there dealing specifically with POSIX parameter expansion which you can find linked to from my profile page, and in which I include quotes from the POSIX guidelines and links thereto. You will also find a few in which I demonstrate other uses of the heredoc, such as reading an entire shell script into a shell variable, parsing and manipulating it programmatically, then finally running its new version all done from within another script or shell function. Just saying.

Answer 3

You can't have the shell process "uninterpreted" input. What you type at the command line is just a string of characters precisely intended to be interpreted by the shell. You can't have the shell pass your literal, typed, characters to a function or command, because it has to interpret them to know what command/function to invoke and with what arguments! When you type something at the command prompt, you have to accept that you have to type according to the rules of shell interpretation (because you're using a shell!).

The rules of shell interpretation are very helpfully chosen. Rather than getting in your way, they give you a way of instructing the shell to do anything you want, including specifying arbitrary arguments to things. Without interpretation, there's no way for the shell to extract an action to execute precisely from your input. Interpretation implies special characters (like space), and without escaping, there would be no way to pass those characters to a command.

Regarding the interpretation itself, I've always found the bash documentation on this to be very good. Briefly, things like tilde expansion happen very early (and tilde expansion only in certain situations). Then, variable substitution and word splitting happen, and finally globbing.