Prev: Run a program under certain amount of physical memory?
Next: Unix scripting - Exclude fileName using For loop
From: Seebs on 20 Jan 2010 16:14
On 2010-01-20, Lao Ming <laomingliu(a)gmail.com> wrote:
> Strange. The reason I have to test for failure is that I
> can't predict what URL will be a problem

Sure, but you don't need to create new shells or anything to
"test for failure".

> and I can't continue
> processing of a file that is either incompletely written or does not
> exist at all. Hmmm. Can a file that is incompletely written be
> tested?

There's no such thing.

A web server could, potentially, yield for you a fragment of an HTML page.
That's a completely written file, but you may not like what you get parsing
it.

You might want to give some thought to the question of what kinds of results
you would find useful. Remember that web pages can also have transient
failures and the like. You might get a redirection page, or a 403 error,
or...

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: bsh on 20 Jan 2010 16:49
Lao Ming <laoming...(a)gmail.com> wrote:
> I have a line of bash code that fails sometimes and there's nothing I
> can do about it except possibly do something on failure. The line of
> code, not being very straight forward, would probably be a distraction
> so I'll simplify it:
>
> ( program -a -b ) > /dev/null

Why does the program need to be executed in a subshell?
Executables are already executed in a subshell environment.
The common programming idioms that require "(...)", like
non-trivial redirections or preventing side-effects upon
the parent environment, is something you are not doing.

> Should I enclose the entire line in another set of parens like this or
> is there a better way to do it?
> (( program -a -b ) > /dev/null ) || error=true
> if [ ! $error ]
> then
> ... normal processing
> else
> ... alternate processing
> fi

(Mind that a "((" in bash3 is the builtin for arithmetric
evaluation, not two consecutive subshells! How does bash(1)
parse such ambiguous syntax? I know ksh(1) would complain.)

Depending upon your specific requirements -- which you
do not state -- and understanding that an "if" statement
tests the return code of _any_ command, not just a "test"
or "[" builtin, I could potentially code like this:

if setupstuff1
setupstuff2
program -a -b >/dev/null # any "silent" CL option available?
then ... normal processing
else ... alternate processing
fi

Only the return code of "program" is tested, while
setupstuff[12] are neatly encapsulated for programmatic
explicability.

=Brian
From: Lao Ming on 20 Jan 2010 17:21
On Jan 20, 1:49 pm, bsh <brian_hi...(a)rocketmail.com> wrote:
> Lao Ming <laoming...(a)gmail.com> wrote:
> > I have a line of bash code that fails sometimes and there's nothing I
> > can do about it except possibly do something on failure.  The line of
> > code, not being very straight forward, would probably be a distraction
> > so I'll simplify it:
>
> >  ( program -a -b  ) > /dev/null
>
> Why does the program need to be executed in a subshell?
> Executables are already executed in a subshell environment.
> The common programming idioms that require "(...)", like
> non-trivial redirections or preventing side-effects upon
> the parent environment, is something you are not doing.

Well, it's more accurately:

( program -a -b -o myfile $url ) > /dev/null

It has undesirable output (not the -o output file) which I redirect
to /dev/null. That part of it is working fine. In fact, I think it
was on comp.unix.shell that I received the suggestion to do it that
way.



> > Should I enclose the entire line in another set of parens like this or
> > is there a better way to do it?
> >  (( program -a -b  )  > /dev/null ) || error=true
> > if [ ! $error ]
> > then
> >     ... normal processing
> > else
> >     ... alternate processing
> > fi
>
> (Mind that a "((" in bash3 is the builtin for arithmetric
> evaluation, not two consecutive subshells! How does bash(1)
> parse such ambiguous syntax? I know ksh(1) would complain.)

Thanks for alerting me to this. I suppose I could be wrong but I
thought a dollar sign had to precede the arithmetic eval in bash.


> Depending upon your specific requirements -- which you
> do not state -- and understanding that an "if" statement
> tests the return code of _any_ command, not just a "test"
> or "[" builtin, I could potentially code like this:
>
> if      setupstuff1
>         setupstuff2
>         program -a -b >/dev/null   # any "silent" CL option available?
> then    ... normal processing
> else    ... alternate processing
> fi
>
> Only the return code of "program" is tested, while
> setupstuff[12] are neatly encapsulated for programmatic
> explicability.
>
> =Brian

Thanks, Brian.

From: bsh on 20 Jan 2010 18:06
Lao Ming <laoming...(a)gmail.com> wrote:
> bsh <brian_hi...(a)rocketmail.com> wrote:
> > Lao Ming <laoming...(a)gmail.com> wrote:
> > > ...

> Well, it's more accurately:
> ( program -a -b -o myfile $url ) > /dev/null

Hmmm. This still doesn't have any construct (like redirection
or side-effects, as mentioned) that would require an additional
subshell "( ... )".

Have you tried the below to see if it is acceptable?

$ program -a -b -o myfile $url >/dev/null

> > (Mind that a "((" in bash3 is the builtin for arithmetric
> > evaluation, not two consecutive subshells! How does bash(1)
> > parse such ambiguous syntax? I know ksh(1) would complain.)
> Thanks for alerting me to this.  I suppose I could be wrong but I
> thought a dollar sign had to precede the arithmetic eval in bash.

You remember the arithmetric _substitution_ builtin, which is
(mostly) identical to arithmetric _evaluation_, but emits the
calculated value of the arithmetric expression to stdout. IIRC,
in bash2 (and zsh(1)?), this used to be "$[ ... ]".

> Thanks, Brian.

You're welcome!

I'll expand on Barry's post by commenting that variable list operators
(var=value var2=value2 var3=value3 ...) always emit the return code
of 0 (success), unless there is a command substitution that sets it.

Also, Despite the issue as mentioned above, your code still would
be problematic because variable "error" is never reset (at least in
your
code extract) -- any additional passes through that code will always
result in an error condition, whether or not "program" has returned an
error or not.

=Brian
From: Seebs on 20 Jan 2010 18:59
On 2010-01-20, Lao Ming <laomingliu(a)gmail.com> wrote:
> Well, it's more accurately:
>
> ( program -a -b -o myfile $url ) > /dev/null
>
> It has undesirable output (not the -o output file) which I redirect
> to /dev/null. That part of it is working fine. In fact, I think it
> was on comp.unix.shell that I received the suggestion to do it that
> way.

Why the ()? This will do exactly the same thing (for essentially any
practical purpose) without them.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
First  |  Prev  | 
Pages: 1 2
Prev: Run a program under certain amount of physical memory?
Next: Unix scripting - Exclude fileName using For loop