From: Jilles Tjoelker <jilles@stack.nl>
To: Vadim Zeitlin <vz-dash@zeitlins.org>
Cc: dash@vger.kernel.org, Harald van Dijk <harald@gigawatt.nl>
Subject: Re: Possibly wrong handling of $_?
Date: Thu, 25 Dec 2014 15:32:26 +0100 [thread overview]
Message-ID: <20141225143226.GA27266@stack.nl> (raw)
In-Reply-To: <E1Y3YxI-0004Qg-GA@smtp.tt-solutions.com>
On Wed, Dec 24, 2014 at 12:33:32AM +0100, Vadim Zeitlin wrote:
> On Wed, 24 Dec 2014 00:21:09 +0100 Harald van Dijk <harald@gigawatt.nl> wrote:
> HvD> On 23/12/2014 23:34, Vadim Zeitlin wrote:
> HvD> > Hello,
> HvD> >
> HvD> > I'm not exactly sure if this is a bug because I didn't find any
> HvD> > specification about how is this supposed to behave (to my surprise it
> HvD> > turned out that $_ was not in POSIX), but please consider this:
> HvD> >
> HvD> > % zsh -c 'echo -n foo && echo $_'
> HvD> > foofoo
> HvD> > % bash -c 'echo -n foo && echo $_'
> HvD> > foofoo
> HvD> > % dash -c 'echo -n foo && echo $_'
> HvD> > foo/usr/bin/dash
> HvD>
> HvD> This does come across as somewhat confusing, but $_ is really not a
> HvD> special variable at all in dash.
> Ah, this does explain it, thanks!
Dash does implement $_, but only in interactive mode.
Your selection of shells makes it appear as if dash is the odd one out,
but in fact it is not. FreeBSD /bin/sh (also an Almquist shell
derivative), mksh and ksh93 also only implement $_ in interactive mode.
Details of how $_ differ as well, particularly in ksh93. It seems unwise
to use this feature in scripts.
> HvD> If dash did something special with $_, then I agree it would be nice if
> HvD> it would be somewhat compatible with other shells. If dash simply does
> HvD> not implement a feature, that feature is not required by any standard,
> HvD> and that feature is not widely used, then I suspect there won't be a lot
> HvD> of interest in implementing that feature.
> Yes, I understand, somehow the idea that dash didn't implement it at all
> just didn't occur to me, but clearly adding a non-standard new feature is
> not nowhere near as important as fixing [what looked like] a bug. I'm not
> sure about the "not widely part", but I don't have any non-anecdotal
> evidence one way or the other.
> HvD> Don't be put off by that, though. You are free, of course, if you feel
> HvD> so, to attempt to convince people $_ is an important feature that all
> HvD> shells should implement. If you have compelling use cases, if it solves
> HvD> real problems, and if many other shells already implement it, you might
> HvD> even get it standardised. I have never seen a need for it, but that's
> HvD> just me speaking from personal experience, others may feel differently.
> FWIW my initial problem started with using
> builddir := $(shell mkdir -p some-long-make-expression && echo $_)
> in a makefile, which seemed like a nice way to assign the value to the
> variable only if the directory was successfully created. This can, of
> course, be done in a myriad of other ways, but this one just seemed like
> the most elegant to me. Whether this counts as a "need" or not is not for
> me to say.
> Personally I'd say the main argument for adding support for "$_" to dash
> would be to avoid mysterious problems like the one I just had because dash
> silently (i.e. without giving any errors) behaves differently from the
> other shells, which in my case resulted in the makefile misbehaving only
> under Debian (where dash is used as /bin/sh) but not under systems.
Such a principle of least surprise is not a design goal for dash.
--
Jilles Tjoelker
next prev parent reply other threads:[~2014-12-25 14:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 22:34 Possibly wrong handling of $_? Vadim Zeitlin
2014-12-23 23:21 ` Harald van Dijk
2014-12-23 23:33 ` Re[2]: " Vadim Zeitlin
2014-12-25 14:32 ` Jilles Tjoelker [this message]
2014-12-25 22:05 ` Harald van Dijk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141225143226.GA27266@stack.nl \
--to=jilles@stack.nl \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
--cc=vz-dash@zeitlins.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox