Re: Bash true/false builtings undocumented? "false" not working?
On Fri, Aug 17, 2018 at 04:36:43PM +0200, email@example.com wrote:
> On Fri, Aug 17, 2018 at 10:12:54AM -0400, Greg Wooledge wrote:
> > On Fri, Aug 17, 2018 at 03:43:58PM +0200, firstname.lastname@example.org wrote:
> > > The construction
> > >
> > > foo && echo "bar" || echo "baz"
> > >
> > > does probably work, because echo's exit status is (always?) 0 (the bash
> > > builtin's documentation mumbles something about "write error").
> > echo can fail if stdout is closed, or if it's redirected to a file that
> > can't be written to (because of a full disk, etc.).
> > Sure, it may work 99.99% of the time, but it's still not safe.
> This particular idiom is still fine, since if stdout gets closed,
> nobody will notice the difference between both branches anyway .
> I still maintain that this pattern is OK, since it's idiomatic and
> highly readable. But of course, you gotta know what you're doing,
> and in which ways it may break down.
It's idiomatic for the C/Java programmer I guess, but now that I'm
beginning to understand the problem Greg points out (and now that I
remember, he posted that a few years ago, and I read it then too, and
now I'm even more grateful because it's so easy to miss the problem
of "mid pipe" failures being different to the "if then else" idiom.
The other part of my personal intention is to have my own code
(wherever it is), be maximally useful to newbies (been helping
someone with bash filename expansion and ? and * wildcards the last
few days) - so in this case, the subtleties are a trap for newcomers
- if they assume (which I had been up until the kind responses in
this thread) that "test && ||" is a reasonable replacement for "if
then else", that is quite likely to eventually cause problems - so I
want to be able to cut and paste my own scripts, and know that I'm
leading the target of my offer down a reasonable and reasonably safe
path, in cases beyond the immediate issue.
> And blog pages like yours are
> invaluable in that (although we may disagree (methodically( somewhat
> in this point, I am thankful that you go to the length of writing
> out those things in a generally accessible manner).
Folks taking the time to explain these things is such clarity is
> Shell only looks simple at first sight.
> It's a nice "little language",
> full of surprises and treasures. But it has to be treated with
> respect :-)
It might be little, but dang it's powerful. And Bash at least is not
really little (here I am, 20 years in, still struggling - although
that might say more about me than about Bash :)
Thank you everyone, really appreciated!
>  https://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest
> somewhat (much) tongue-in-cheek :-P
> -- t