Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16278
| From | Robert Elz <kre@munnari.OZ.AU> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: greater-than + number sign = newlines in history |
| Date | 2020-05-04 21:24 +0700 |
| Message-ID | <mailman.2071.1588602273.3066.bug-bash@gnu.org> (permalink) |
| References | <be89d8aa-e9db-bb3d-a874-b6d1e2a57790@case.edu> <bb08b099-59bd-5f04-4074-bbc046e99c6c@gmx.de> <2429.1588602246@jinx.noi.kre.to> |
Date: Mon, 4 May 2020 08:58:08 -0400
From: Chet Ramey <chet.ramey@case.edu>
Message-ID: <be89d8aa-e9db-bb3d-a874-b6d1e2a57790@case.edu>
| The command-oriented history mode has to pay attention to those, ['#']
| because shell comments are one place where you can't
| replace a newline with a semicolon.
That makes sense.
| It just needs to also pay attention to
| the fact that bash is reading a here-document.
There is more to it than that.
If I do (type):
while sleep 4
do
echo abc#def
done
(where the indentation is just for the e-mail), what bash puts in
history is
while sleep 4; do echo abc#def
done
(again indentation just for e-mail). The # there is not a comment, and
if I quoted the arg to echo, I'd get
while sleep 4; do echo "abc#def"; done
Only words starting with # need special treatment, not just any random '#'.
(The code is correctly executed, of course, and abc#def is printed every
4 secs.
However, while this one looks weird, it isn't actually incorrect,
unlike the here-doc one.
| This was reported and fixed in October, 2019, and the fix is in the devel
| branch.
That one probably deserves a patch.
kre
Back to gnu.bash.bug | Previous | Next | Find similar
Re: greater-than + number sign = newlines in history Robert Elz <kre@munnari.OZ.AU> - 2020-05-04 21:24 +0700
csiph-web