Re: soliciting opinions about potential new cron/at features.
On 25 Feb 1999, Roderick Schertler wrote:
> The real ugly part about this is that you've got to parse at's stderr in
> order to get the id. (Let alone for now that this informational message
> is on stderr rather than stdout, this design bug looks to be widespread
> and historic.) Also, the format varies. Here's what it looks like on
> the systems I have handy:
>
> Linux:
> warning: commands will be executed using /bin/sh
> job 43 at 1999-02-25 13:15
>
> SCO:
> warning: commands will be executed using /bin/sh
> job 920049300.a-18260:0 at Fri Feb 26 13:15:00 1999
>
> DGUX:
> UX:at: WARNING: Commands will be executed using /usr/bin/sh
> UX:at: INFO: Job 919966501.a at Thu Feb 25 13:15:00 1999
You could easily use sed to parse it:
sed -e 1d -e 's/^.*[Jj][Oo][Bb] \([^ ]*\) .*$/\1/'
Use this command in some sort of pipe. It will:
- delete the first line
- on every other line (there is only one other line), replace the whole
line with the word after the string 'job ', where 'job' is not case
sensitive.
It works on the three examples you gave, but I can't guarantee it will
work on all platforms.
To pipe command1's stderr as well as its stdout into command2, do:
command1 2>&1 | command2
To pipe only stderr (and discard stdout), do:
command1 2>&1 >/dev/null | command2
I suspect you could use perl to do the same in a much more flexible way,
but I don't know much of perl.
Remco
Reply to: