Re: [exim-dev] the use of >> in example Shell code in the do…

Top Page

Reply to this message
Author: Ivan Shmakov
To: exim-dev
Subject: Re: [exim-dev] the use of >> in example Shell code in the documentation
>>>>> Phil Pennock <pdp@???> writes:
>>>>> On 2012-01-15 at 20:23 +0700, Ivan Shmakov wrote:


>> # rm -f new-params
>> # touch new-params
>> # chown exim:exim new-params
>> # chmod 0400 new-params
>> # certtool --generate-privkey --bits 512 >new-params
>> # echo "" >>new-params
>> # certtool --generate-dh-params --bits 1024 >> new-params
>> # mv new-params gnutls-params
>> --cut: --

>> Arguably, it doesn't make sense to use >> here. Also, while it

> Yes it does. The first invocation of certtool will truncate, the
> echo and second invocation append. The logic is correct.

    I contest the style, not the logic.  The code above open(2)'s
    the same file thrice, while it could easily open it only once.


>> Consider, e. g., the following example code instead:

 >> #!/bin/sh
 >> rm -f new-params
 >> umask 0277
 >> {
 >>     certtool --generate-privkey --bits 512
 >>     echo ""
 >>     certtool --generate-dh-params --bits 1024
 >> } > new-params
 >> chown exim:exim new-params
 >> mv new-params gnutls-params

> Looks good, although my recollection is that in some older shell on
> some systems (which Exim runs on), braces for command-pipelines don't
> redirect well and you'd need to use parentheses and a sub-shell.


    (Also, exec > new-params may be used here instead, though for
    safety, it'd be necessary to redirect stdout elsewhere after the
    final certtool(1) invocation, which seems overly verbose.)

>> Should something like mktemp(1) be used as well, the rm(1)
>> vs. touch(1) race will also be avoided, and it will be perfectly
>> safe to run multiple instances of the code above at once. (Just as
>> with Exim computing new D-H parameters by itself.)

> The rm vs touch race is non-existent, because this is not happening
> in /tmp, but in the Exim spool directory which is only writeable by
> the Exim run-time user (and root). The target file is replaced
> atomically. Any process which can interfere with the file creation
> can already do anything at all that the Exim processes can do.

    The issue is that there may be several simultaneously-running
    instances of the code above.  These may open the same new-file
    and write to it simultaneously.  (Though the chances are that
    one wouldn't ever experience such a behavior in practice.)

> The hoops to be jumped through for /tmp and its like are not needed
> in this case.

    The primary reason behind mktemp(1) is that it allows for safe
    (O_CREAT | O_EXCL) file creation in Shell, which is seemingly
    impossible by any other (conventional) means.

> I'm unconvinced that anything here needs to change.

FSF associate member #7257