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 <[email protected]> wrote: > Hi Nala, > > Nala Ginrut <[email protected]> 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
