[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