RFC: shell-safe version of string_sub()?

[Jean Francois Micouleau]

On Thu, 19 Oct 2000, Peter Samuelson wrote:

> CVS SAMBA_2_2 but probably applies more broadly ---
> 
> Barely-relevant background:
> 
>   The other day I set up a ps2pdf server using a print queue, a share,
>   Ghostscript, and minimal glue.  Works great.  (And spoolss *rules*!)
>   However, I ran into a glitch with the 'print command' option.
> 
> In print_job_end() (printing.c), the lp_printcommand() shell command
> undergoes some substitutions such as '%J' for the print job name.
> pstring_sub() calls string_sub() which mangles the job name to convert
> several characters to underscores.  I managed to hit a corner case
> somewhere with a print job with a space in the name -- the space didn't
> get converted.  This of course caused my script to fail.

IMNSHO, %J substitution shouldn't be mangled at all. IIRC, this mangling
is from previous printing database time.

The only mangling that should happen is adding quotes around the string.


	J.F.


> I know I could just quote the args myself:
> 
>   print command = /usr/local/bin/my_script -u "%U" -n "%J" "%f"
> 
> instead of
> 
>   print command = /usr/local/bin/my_script -u %U -n %J %f
> 
> but this is cheesy -- and we're still losing information as other
> characters become underscores.  I would like to propose an alternate
> function, call it string_sub_sh(), which instead of the string_sub()
> mangling does shell-metacharacter mangling.  Basically anything not in
> the list [A-Za-z0-9/=+_-] is backslashed.  That should be safe in all
> known shells (known to me, that is).  Perhaps decimal 160-254 are OK
> too -- they are in at least some shells.
> 
> That way shell command lines don't need to use quoting, which is
> counterintuitive ("do I use single quotes or double quotes?").  Of
> course one still has to tread carefully if the resulting command is a
> Bourne or (horrors) csh script, but not if it's (say) C or Perl.  And
> this case is IMHO analogous to setuid -- nobody sane would use plain
> shell here if doing anything nontrivial.
> 
> Anyway, I imagine string_sub_sh would be useful lots of other places in
> the corpus as well -- quite a few functions have to compose shell
> command lines, right?  Does anyone else think I'm on to something here?
> I'll try to find time to write a patch in the next 24 hours or so --
> for me if no one else.
> 
> Peter
>