How to set specific file permissions when redirecting output?

Question

This is probably a duplicate, but all my searches are turning up questions about permission denied errors.

I am running a command in a bash shell. I want to redirect output to append to a file that probably does not exist on the first run. I want to set specific file permissions mode if output redirection has to create this file. Is there a way to do this with one command?

For example, I might try

foo >> /tmp/foo.log 0644

where 0644 are the permissions I want foo.log to end up with. Most commands I've experimented with in bash end up interpreting 0644 as an additional argument to foo.

I get the feeling that this is going to take a second command to chmod the permissions before or after writing to it.

I am using GNU bash 4.2.25 and Ubuntu 12.04, if that makes a difference - general answers are preferred.

Answer 1

There's no way to do it while piping as far as I know, a simple script might be the best solution.

if [ -e /tmp/foo.log ]; then
    foo >> /tmp/foo.log
else
    foo >> /tmp/foo.log
    chmod 0644 /tmp/foo.log
fi

Answer 2

I know it's an old question, but I wanted to add my two cents.

I had the same idea and came up with a solution similar to BowlesCR. The problem with his solution was that my command (foo) wouldn't work if I changed the umask before running it, so this is my take on the problem:

foo | ( umask 0033; cat >> /tmp/foo.log; )

Here, umask only affects the redirection to foo.log in the subshell. Everything else remains unaffected.

A bit convoluted, but it works.

Answer 3

Without true scripting, you can chain a bit:

touch /tmp/foo.log; chmod 0644 /tmp/foo.log; foo >> /tmp/foo.log

Effectively similar to Slowki's answer, but condensed into a one-liner.

The only other thing I can think of is tinkering with the umask. Best to do this in a subshell so it doesn't pollute the current environment:

(umask 0033 && foo >> /tmp/foo.log)

Two issues with that, though.

1. Umask can't raise the permissions above the level specified in the creat() syscall (0666 appears to be what Bash uses).
2. This won't change the permissions on an existing file (because umask applies only to file creation).

Answer 4

When the redirection sets the wrong permissions, e.g.:

$ rm capture.*
$ perl -e 'print STDERR "$$ STDERR\n"; print STDOUT "$$ STDOUT\n"' \
                            >> capture.STDOUT 2>> capture.STDERR
$ perl -e 'print STDERR "$$ STDERR\n"; print STDOUT "$$ STDOUT\n"' \
                            >> capture.STDOUT 2>> capture.STDERR
$ ls -l capture.*
-rw-rw-rw- 1 jcookinf jcookinf 22 Jun 12 10:38 capture.STDERR
-rw-rw-rw- 1 jcookinf jcookinf 22 Jun 12 10:38 capture.STDOUT
$ cat capture.*
215 STDERR
216 STDERR
215 STDOUT
216 STDOUT

I believe you can use something like xynomorf gave, and address the stderr concern from Orsiris de Jong with a slight modification to use the bash process substitution.

$ rm capture.*
$ perl -e 'print STDERR "$$ STDERR text\n"; print STDOUT "$$ STDOUT text\n"' \
            > >(umask 0033; cat >> capture.STDOUT) 2> >(umask 0033; cat >> capture.STDERR)
$ perl -e 'print STDERR "$$ STDERR text\n"; print STDOUT "$$ STDOUT text\n"' \
            > >(umask 0033; cat >> capture.STDOUT) 2> >(umask 0033; cat >> capture.STDERR)
$ ls -l capture.*
-rw-r--r-- 1 jcookinf jcookinf 32 Jun 12 10:43 capture.STDERR
-rw-r--r-- 1 jcookinf jcookinf 32 Jun 12 10:43 capture.STDOUT
$ cat capture.*
233 STDERR text
238 STDERR text
233 STDOUT text
238 STDOUT text

Naturally, use umask 0077 to get mode 600 and prohibit any other users from seeing the contents.