[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] consequence: spawn
- To: herbstluftwm _minus_ devel _at_ lists _dot_ sourceforge _dot_ net
- Subject: Re: [PATCH] consequence: spawn
- From: Christoph Egger <christoph _at_ christoph _minus_ egger _dot_ org>
- Date: Thu, 13 Dec 2012 10:53:01 -0800
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