On 2009-07-01 10:14 +0200, Todd A. Jacobs wrote:
> I noticed that a bash script of mine was causing permission errors under
> cron, so I had to change it like so:
>
> --- boxmail.sh 2009/06/30 09:01:46 1.10
> +++ boxmail.sh 2009/07/01 08:01:51
> @@ -167,7 +167,7 @@
>
> # Echo message to standard error.
> function stderr {
> - echo "$*" > /dev/stderr
> + echo "$*" >&2
> }
>
> # Display warnings on standard error.
>
> I did a little minor testing with cron, and >&2 works while /dev/stderr
> doesn't. Now, I know that "/dev/stderr" is a bashism,
Actually, it might be not. On my system, /dev/stderr exists and is a
symlink to /proc/self/fd/2, i.e. the standard error channel of the
current process. Thus it works fine with dash.
> but since cron is
> executing boxmail.sh (with an explicit bash shebang) rather than
> executing the code directly, why would the bashism come back with:
>
> From: Cron Daemon
> To: nospam
> Subject: Cron <nospam> $HOME/bin/boxmail.sh
> Date: Wed, 1 Jul 2009 00:00:02 -0700 (PDT)
>
> /home/nospam/bin/boxmail.sh: line 170: /dev/stderr: Permission denied
>
> The bash manual doesn't say anything about a requirement that the shell
> be interactive to use /dev/stderr, so why is this happening?
Does the script work if you run it by hand? Right now I have no idea
why /dev/stderr should not be writable.
Sven
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
