Re: [Proposal] Why not add a "shell" procedure?

[Nala Ginrut <nalaginrut@gmail.com>]

hi Mark! Thanks for reply!
One reason to proposal this "shell" is to handle these metacharacters
in programming way. I think it's easier than input them with keyboard.
So my vote is to provide a more safer "shell" and encourage it rather
than using raw "open-pipe*".
What do you think?


On Mon, May 14, 2012 at 2:29 AM, Mark H Weaver <mhw@netris.org> wrote:
> Hi Nala,
>
> Nala Ginrut <nalaginrut@gmail.com> writes:
>> (define %current-shell (getenv "SHELL"))
>> (use-modules (ice-9 popen) (rnrs io ports))
>> (define shell
>>    (lambda (cmd)
>>        (let ((str (string-append %current-shell " -c " cmd)))
>>           (get-string-all (open-pipe str OPEN_READ)))))
>
> (open-pipe <STRING> ...) already does '/bin/sh -c <STRING>', so (shell
> <STRING>) does '/bin/sh -c "<SHELL> -c <STRING>"', i.e. it launches a
> shell within a shell.  This is wasteful, and might also exacerbate
> problems when shell metacharacters are present in <STRING> or <SHELL>.
>
> Therefore, better do (open-pipe* OPEN_READ %current-shell "-c" cmd)
> instead.
>
> Also, I recommend making '%current-shell' a fluid, and perhaps adding a
> keyword argument to 'shell' to specify the shell directly, so that
> '%current-shell' is only used as the default for the keyword argument.
>
> Note that although it is convenient to pass strings directly to the
> shell, it is fraught with security risks due to the complexity of
> escaping shell metacharacters properly, especially given the diversity
> of shells and shell configurations.  Therefore, it is better not to
> encourage this way of doing things.  It is generally better to use
> 'open-pipe*' or 'system*' directly, to avoid the shell entirely.
>
>     Thanks,
>       Mark