Re: [Help-bash] pass command to script

[Eric Blake]

On 4/25/19 1:24 PM, Greg Wooledge wrote:

> Now let's say I type this:
> 
>   ssh host rm -f "$file"
> 
> This is where things break.
> 
> A naive reading says that this should be OK.  The ssh client takes the
> argument words 'rm' and '-f' and 'somefilename' (the last was expanded by
> my shell on the client before ssh was invoked) and passes them to the
> server.  The server sees the string 'rm -f somefilename' and passes it to
> my shell to be parsed and executed.
> 

> Now, this is the same problem that Christof is trying to solve.  He wants
> to write something that is basically ssh, and has to deal with the same
> issues that ssh deals with when someone passes a command to it.
> 
> If he manages this, he will have achieved something that rsh/remsh/ssh
> did not manage to achieve.  If he does it, I hope he also invents a time
> machine (which might be a simpler task), and goes back and teaches the
> authors of remote-shell how it should be done.

Am I recalling correctly that at one point, there was an experiment made
where the shell was patched to export an environment variable describing
which portions of the command line were typed directly vs. which parts
were quoted or otherwise resulted from expansions, so that the invoked
application could read that environment variable to reconstruct a
properly quoted command line that would have the same behavior?  Sadly,
I did not have the right search terms to point to an internet article
describing that experiment, or why it was withdrawn (although I suspect
that the overhead of having the shell compute that environment variable
for every command run even where it was not used, plus the problem of
what to do if the child process did not clear that environment variable
before executing a grandchild process where the contents of that
variable are no longer useful, probably played a role. Also, consider
the case of 'ls *' in a heavily-populated directory where the glob
results alone fits within your system's limits for argv/environ space to
execv3(), but where adding your environment variable pushes you over the
limit and causes E2BIG failure).

> 
> Personally, I doubt it can be done with anything less powerful than a
> complete shell syntax analyzer.  You'd need a program that can understand
> the context of every single character of the input argument list and
> know whether that character should be quoted or left alone, so that the
> resulting string can be passed to a shell to achieve the same semantics
> as the command that was presumably typed by the user to produce the
> argument list seen by the program.  (Remember, the program does not see
> the original command typed by the user.  There is quote removal as well
> as a slew of substitutions, all of which are done before the program sees
> the input.)

Having the shell output an environment variable alongside $_ that
describes the original command would presumably have to be part of the
way to get at that information. But just because I seem to recall the
experiment does not mean I necessarily think it is worth repeating.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature