[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] consequence: spawn



Thorsten WiÃmann <edu _at_ thorsten _minus_ wissmann _dot_ de> writes:
> > One approach was to pass the string as a '-c' argument to /bin/sh using
> > fork() and execl(). This is less code, but I don't know if /bin/sh is
> > depended anywhere else in the source (although Im pretty sure 99.9999% of
> > users are using a POSIX shell).
>
> This creates a hard dependency to /bin/sh and assumes /bin/sh behaves
> correctly for -c.

interwebs:
> But not necessarily for /bin/sh SUSv3 talks about the POSIX
> shell which is named "sh" and first in the PATH returned by getconf
> PATH

SUSv3 [0]:
> The shell shall read its input in terms of lines from a file, from a
> terminal in the case of an interactive shell, or from a string in the
> case of sh -c or system(). The input lines can be of unlimited
> length. These lines shall be parsed using two major modes: ordinary
> token recognition and processing of here-documents.

=> You can assume `sh -c` to exist and work as expected on anything that
   adheres to POSIX ;-) there are similar provisions in LSB so I
   wouldn't be too scared of that.

Regards

    Christoph

[0] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02
    accessible from UC network might be behind a paywall elsewhere