[cap-talk] Don't put capabilities in argv?
David-Sarah Hopwood
david-sarah at jacaranda.org
Wed Sep 16 13:55:58 PDT 2009
Ben Laurie wrote:
> On Wed, Sep 16, 2009 at 4:06 AM, Zooko O'Whielacronx <zookog at gmail.com> wrote:
>> We had this problem in Tahoe-LAFS (thanks to Kevin Reid for pointing
>> it out). We added a Tahoe-LAFS-specific feature to generate a new cap
>> and then use it instead of the old way of generating it with one
>> command and then passing it in the argv of a second command.
>>
>> It seems to me that you could achieve a fairly general solution if you
>> can rely on having bash -- you can define bash functions that pass
>> arguments on stdin instead of in argv:
>>
>> # f takes one argument -- a cap
>> # real_f reads the head of its stdin to get its argument
>> function f {
>> echo $1 | real_f
>> }
>
> And in sh.
Apparently this syntax is not defined in POSIX
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_04>:
# The following words may be recognized as reserved words on some
# implementations (when none of the characters are quoted), causing
# unspecified results:
#
# [[ ]] function select
POSIX does define a function definition syntax that bash also accepts [*]:
<http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_05>
f() {
echo $1 | real_f
}
[*] Tested on 'GNU bash, version 3.2.17(15)-release (i686-pc-cygwin)'.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the cap-talk
mailing list