Re: Could bash do what make does?
On 29/11/16 05:41, Robert Durkacz wrote: > make has survived all this time but it is not very well accepted today > with a lot of competing build systems trying to do better. bash is > very secure and moreover the Bourne shell was there first. make is > falling out of favour as far as I can see even though it has had a > very good run: Kernighan and Pike in their book on Unix said to use it > in preference to the shell for builds. That is the background to my > asking was it really necessary after all to do give up on the shell > for doing builds? It seems a little perverse to me to have huge features added to bash for social reasons. make does its job well, and in the majority of cases it either shells out to bash or can be made to do so. The Bourne shell may have a legacy but I don't think that means that people will immediately adopt bash's make-like features if they ever happen. (Besides, bash is not the Bourne shell, and the other Bourne shell derivatives probably won't follow suit.) Regardless of that, make does a lot more than just check file times. It checks whole dependency trees and builds common dependencies just once, and it can schedule build tasks in parallel safely (providing the makefile is well-written). It can have generic rules defined which determine how to build a filetype in general, and will follow those rules when they're needed to build a dependency of another target. It has a lot of helpful features you can see in its man page, and I'd hate to see people ditching make for a simplified imitation built into a popular shell. Even then, if the implementation isn't simplified, and feature parity with make is achieved, the resulting build system would rely on a weird kind of makefile which is incompatible with systems running older versions of bash. You might as well have written a proper makefile instead. (That's to say nothing of how awkward it would be to specify a non-deterministic ordering of jobs and a proper dependency tree in bash's syntax.) In short: - make does its job very well. - bash's popularity doesn't mean people will automatically adopt new features. (Ever seen a shell script using "coproc" in the wild?) - Reimplementing it is no mean feat. - If you reimplement it, you just have make all over again, so just use make. If someone wants to build their project using waf or something instead, that's their own prerogative. That kind of person would probably overlook a native bash build system too, because I feel like there are a lot of Python (/Ruby/etc.) programmers with a visceral disdain for shell scripting. It'll take a lot to change that. But I'm not related to the Bash project in any meaningful way, so there's a chance that the regulars won't think the same. signature.asc Description: OpenPGP digital signature
Re: [PATCH] Readline not being able to handle long lines
On Tue, Nov 29, 2016 at 12:47:26PM +0500, Mihail Konev wrote:
> On Tue, Nov 29, 2016 at 08:27:00AM +0500, Mihail Konev wrote:
> > Msys2 on windows, at least, should do it without a problem.
>
> Tried both it (bash 4.3.46) and arch linux in qemu (bash 4.3.46).
> Neither reproduced.
>
> Nevertheless, MSYS2 was exhibiting the bug all the time, most likely,
> with bash 4.3.46.
>
> Perhaps this has to do with ^Z and fg ...
>
> ... but the real linux system exhibits it, straight from the console login.
> And in terminal emulators too.
>
> And the patch helps on f459cbd8be37b28be1dc90315e0ab51d7f211301,
> i.e. bash 4.4.5
>
> Would now try to hit this on MSYS2 again :)
It was triggered by PS1.
Buggy:
PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[35m\]$MSYSTEM\[\e[0m\]
\[\e[33m\]\w\[\e[0m\]\n\$ '
Buggy (replace the ^-sequences in the second line):
PS1="[\${PWD##*/}]\$ " # set the prompt
PS1="^[]0;\$PWD^G^M$PS1"# set the window title
Does not trigger:
PS1='\[\e]0;WINDOW_TITLE_HERE \w\a\][${PWD##*/}]\$ '
Does not trigger:
PS1='[bash]$ '
For the second one, replacing ${PWD##*/} with 'bash' does not help.
But commenting out the set-window-title does.
Escape sequences were all googled/copypasted.
Re: [PATCH] Readline not being able to handle long lines
On Tue, Nov 29, 2016 at 08:27:00AM +0500, Mihail Konev wrote: > Msys2 on windows, at least, should do it without a problem. Tried both it (bash 4.3.46) and arch linux in qemu (bash 4.3.46). Neither reproduced. Nevertheless, MSYS2 was exhibiting the bug all the time, most likely, with bash 4.3.46. Perhaps this has to do with ^Z and fg ... ... but the real linux system exhibits it, straight from the console login. And in terminal emulators too. And the patch helps on f459cbd8be37b28be1dc90315e0ab51d7f211301, i.e. bash 4.4.5 Would now try to hit this on MSYS2 again :)
Re: [PATCH] Readline not being able to handle long lines
On Tue, Nov 29, 2016 at 01:27:26PM +0500, Mihail Konev wrote:
> Buggy:
> PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[35m\]$MSYSTEM\[\e[0m\]
> \[\e[33m\]\w\[\e[0m\]\n\$ '
>
Not a buggy one.
It does not trigger the bug.
> Buggy (replace the ^-sequences in the second line):
> PS1="[\${PWD##*/}]\$ " # set the prompt
> PS1="^[]0;\$PWD^G^M$PS1"# set the window title
>
Turns out this was the only one buggy.
So it was all the (mis-) googled PS1 customizations,
that are actually incompatible with bash 3.2.0 and higher.
Re: bash 4.4 infinite loop while handling SIGTTIN
Hello, Thank you for the very fast reply, though I'd like to shamelessly ask for more bits of your time. I've strace'd all the involved processes (as far as I know), and all were just getting the SIGTTINs, no one was sending SIGCONTs ( http://i.imgur.com/n5bUQVM.png - 25799 a bash process, and even the bash (pid 7026) not in the picture that was just doing pselect(...) on the terminal, the atom processes, and the bash process that goes haywire ). Also, if the default behavior for SIGTTIN is to stop, why bash isn't stopping? How come the kernel isn't stopping it either? (And then if not, where's the read() that should return EIO?) (Even after stopping the parents (except 7026) http://i.imgur.com/F4nOyKx.png bash was sending the SIGTTINs http://i.imgur.com/i74SI0r.png .) Thanks again! On Mon, Nov 28, 2016 at 10:37 PM, Chet Ramey wrote: > On 11/28/16 4:11 AM, pasthe...@gmail.com wrote: >> Hello, >> >> I'm using this package: bash_4.4-2ubuntu1_amd64.deb ( >> http://de.archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.4-2ubuntu1_amd64.deb >> ), but the same behavior happens with bash 4.3. >> >> This seems to be the bug (feature?): >> http://stackoverflow.com/questions/13718394/what-should-interactive-shells-do-in-orphaned-process-groups >> >> I experience the bug when I launch Atom (a text editor so fancy it takes >> ages to start, maybe that's why it waits for an infinite loop ... >> https://github.com/atom/atom/issues/13317 ). >> >> Any thoughts on this? Is this something unavoidable by bash, or it's a bug? >> (Maybe it's a known bug?) > > Basically, the problem is how to run a interactive shell that reads from > the tty when you're not a member of the foreground process group. The bash > strategy will get you the default behavior for SIGTTIN, which will stop > the process. The assumption is that there will be some parent process > willing to handle the stop, not just automatically send a SIGCONT, and bash > expects to be started with SIGTTIN set to the default disposition, not > blocked. > > Chet > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] Readline not being able to handle long lines
On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote:
> > Buggy (replace the ^-sequences in the second line):
> > PS1="[\${PWD##*/}]\$ " # set the prompt
> > PS1="^[]0;\$PWD^G^M$PS1"# set the window title
> >
>
> Turns out this was the only one buggy.
> So it was all the (mis-) googled PS1 customizations,
> that are actually incompatible with bash 3.2.0 and higher.
This is just plain wrong in any bash version. Any part of the prompt that
does not cause the cursor to change position needs to be protected inside
\[ \]. Thus, the sequence from ESC to BEL on line 2 of your script should
be inside \[ \].
Using a CR (^M) probably screws things up as well. I don't even know why
you have that in there. If you want to ensure the prompt always starts
on a new line, use a newline instead of a CR, which will presumably
start to overwrite the last line of the previous command's output, if
that output doesn't end with a newline of its own. I would not expect
this to be the desired behavior.
In any case, you have a working prompt in your original email, so you
could just stick with that one.
Re: [Bash 4.4.5] Variable indirection, error on empty variable
On 11/27/16 5:07 AM, Otenba wrote:
> Bash Version: 4.4
> Patch Level: 5
> Release Status: release
>
> Description:
> Performing variable indirection using an empty value causes an error. It
> didn't in Bash 4.3.
It's pretty clear that indirect expansion that attempts to reference
through an unset variable or a variable whose value is null should be an
error. Bash-4.3 didn't have the greatest error checking, and bash-4.4
catches the null value case. I'll fix it to catch the unset variable
case, too.
> Repeat-By:
> $ reference=1
> $ echo ${!indirect} #variable indirection using an unset variable
If you think of indirect expansion as just a simple string replacement,
though it's more complicated than that, it's clear that this is logically
equivalent to echo ${}, which should be an error.
> $ indirect=
> $ echo ${!indirect} #variable indirection using an empty variable
> -bash: : bad substitution
Using the same logic as above, this expands to the equivalent of
echo ${" "}, which is another obvious error, though the message could
be a little better.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4.4 infinite loop while handling SIGTTIN
On 11/29/16 1:32 AM, Pas wrote:
> Hello,
>
> Thank you for the very fast reply, though I'd like to shamelessly ask
> for more bits of your time.
>
> I've strace'd all the involved processes (as far as I know), and all
> were just getting the SIGTTINs, no one was sending SIGCONTs (
> http://i.imgur.com/n5bUQVM.png - 25799 a bash process, and even the
> bash (pid 7026) not in the picture that was just doing pselect(...) on
> the terminal, the atom processes, and the bash process that goes
> haywire ).
The original strace from the stackoverflow post shows pretty clearly that
SIGTTIN is being ignored:
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fd5f6989d80}, {SIG_DFL,
[], SA_RESTORER, 0x7fd5f6989d80}, 8) = 0
And it looks like that is the original signal disposition for SIGTTIN.
>
> Also, if the default behavior for SIGTTIN is to stop, why bash isn't
> stopping? How come the kernel isn't stopping it either? (And then if
> not, where's the read() that should return EIO?)
You can block or ignore SIGTTIN, and you can start bash wih it blocked
or ignored. That will defeat bash's attempts to stop itself by sending
SIGTTIN. The loop in the stackoverflow post shows that the original
disposition for SIGTTIN is SIG_IGN, but I don't know why the process
isn't being stopped after the SIG_DFL/kill steps.
No read happens until bash determines that it's in the terminal's
foreground process group. This is all part of trying to get job control
initialized, well before the shell attempts to read from the terminal.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: correct error message?
On 11/26/16 1:01 PM, L A Walsh wrote:
> But this didn't (misspelling of hash name):
>
>> if [[ ${requirs[xxx]:-} ]]; then echo ok; else echo not; fi
> bash: xxx: unbound variable
>
> Shouldn't it have said:
>
> bash: requirs: unbound variable?
No. Bash performs array referencing `inside out', and always has. When
asked to find the value for ${var[sub]}, bash first looks at `var' only
to find out what kind of expansion `sub' has to undergo. In all cases, it
expands `sub' for compatibility with other shells that implement arrays
(primarily ksh93), because callers expect the side effects involved in
expanding the array subscript to take place. In this case, it performs
arithmetic expansion on the subscript, which involves expanding identifiers
as variables, resulting in the `unbound variable' message.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
inputrc do-lowercase-version self-referential footgun
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/usr/src/bash-4.3.46-7.x86_64/src/bash-4.3 -I/usr/src/bash-4.3.46-7.x86_64/src/bash-4.3/include -I/usr/src/bash-4.3.46-7.x86_64/src/bash-4.3/lib -DWORDEXP_OPTION -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/usr/src/bash-4.3.46-7.x86_64/build=/usr/src/debug/bash-4.3.46-7 -fdebug-prefix-map=/usr/src/bash-4.3.46-7.x86_64/src/bash-4.3=/usr/src/debug/bash-4.3.46-7 uname output: CYGWIN_NT-6.3 Lenovo-PC 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin Machine Type: x86_64-unknown-cygwin Bash Version: 4.3 Patch Level: 46 Release Status: release Description: * There's a footgun in inputrc processing. # Footgun! # Control-y: do-lowercase-version # WEDGES GOOD! # Not a footgun. # Probably because do-uppercase-version isn't actually recognized. # Control-Y: do-lowercase-version # Control-y: do-uppercase-version Repeat-By: Put the "WEDGES GOOD!" line above into your ~/.inputrc. C-x C-r echo $$ C-y Go kill $$ from some other terminal.
Review of Readline command documentation
Bash Version: 4.4 Release Status: release Description: I attempted a comprehensive review of Readline command documentation, similar to what I did for Readline variables earlier this year. Thank you for incorporating so many fixes into Bash 4.4. * emacs-editing-mode: is documented in rluser.texi but not the manpage. * vi-editing-mode: Ditto. * old-menu-complete: is not documented anywhere except the FAQ. * do-uppercase-version: documented but not implemented(!?) Did I get the _good_ crack? $ grep -rl do.uppercase bash-4.4 bash-4.4/doc/bash.html bash-4.4/doc/bash.info bash-4.4/doc/bashref.dvi bash-4.4/doc/bashref.html bash-4.4/doc/bashref.info bash-4.4/doc/bashref.ps bash-4.4/lib/readline/doc/rluser.texi * Readline commands not documented at all: arrow-key-prefix appears to be dead code? Might be a good time to remove it since readline just bumped its major version number. backward-byte live code, tied up with multibyte character handling and deprecated, undocumented "byte-oriented" readline variable byte-oriented nowadays appears to be a way to make Bash behave multibyte-ignorantly if it was compiled with multibyte awareness (it's ALWAYS tested like this: if (MB_CUR_MAX > 1 && !rl_byte_oriented) or boolean-isomorphically thereto) do-lowercase-version very much alive, see lib/readline/text.c:1047-1056 also bound to many keys by default, so should be documented PROPOSED LANGUAGE: (simply apes do-uppercase-version, mutatis mutandis) If the metafied character x is uppercase, run the command that is bound to the corresponding lowercase character. XXX: Are loops detected between this and do-uppercase-version? No, but that's only because one of them doesn't actually exist. forward-byte see backward-byte above history-substring-search-backward Added in 4.3. history-substring-search-forward Ditto. non-incremental-forward-search-history-again live code, underneath rl_vi_search_again but also directly accessible non-incremental-reverse-search-history-again Ditto. paste-from-clipboard Not documented except in CHANGES, NEWS. tty-status Not documented. vi-append-eol None of the vi readline commands are documented; a glance at historical Bashes (1.14.7, 2.05b, 3.2.57) suggests that they never were. This might be because either: 1) no one loves both readline _and_ vi; or 2) vi is so intuitive that it doesn't require documentation. If only we'd noticed 30 years ago... vi-append-mode vi-arg-digit vi-bWord vi-back-to-indent vi-backward-bigword vi-backward-word vi-bword vi-change-case vi-change-char vi-change-to vi-char-search vi-column vi-complete vi-delete vi-delete-to vi-eWord vi-end-bigword vi-end-word vi-eof-maybe vi-eword vi-fWord vi-first-print vi-forward-bigword vi-forward-word vi-fword vi-goto-mark vi-insert-beg vi-insertion-mode vi-match vi-movement-mode vi-next-word vi-overstrike vi-overstrike-delete vi-prev-word vi-put vi-redo vi-replace vi-rubout vi-search vi-search-again vi-set-mark vi-subst vi-tilde-expand vi-yank-arg vi-yank-to Ditto. Would you like a patch documenting these? _I_ love both vi and Readline... Wishlist items == * wishlist: show-mode-in-prompt should xref emacs-mode-string, vi-cmd-cmode-string, vi-ins-mode-string * wishlist: No need to repeat language about readline commands unbound by default. (in my opinion) + overwrite-mode "By default, this command is unbound." + menu-complete "but is unbound by default." + menu-complete-backward "This command is unbound by default." + delete-char-or-list "This command is unbound by default." + skip-csi-sequence "This is unbound by default, but usually bound to ESC-[." (explain rationale for this in rluser.texi? Is it a sledgehammer for people with broken termcap/terminfo driven insane by escape sequence crud echoing at the prompt?) * wishlist: From the manpage, remove potentially confusing language about what the readline command (menu-complete) is "intended" to be bound to. rluser.texi is a better place to suggest that people can bind menu-complete instead of complete to TAB. * edit-and-execute-command description should put a space between the keystrokes, like all the the other multi-key sqeuence bindings. Issue appears in both bash.1 and rluser.texi. * wishlist: Add some further notation explanation at "Readline Command Names". PROPOSED LANGUAGE:
Re: [PATCH] Readline not being able to handle long lines
On Tue, Nov 29, 2016 at 10:02:08AM -0500, Greg Wooledge wrote:
> On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote:
> > > Buggy (replace the ^-sequences in the second line):
> > > PS1="[\${PWD##*/}]\$ " # set the prompt
> > > PS1="^[]0;\$PWD^G^M$PS1"# set the window title
> > >
> >
> > Turns out this was the only one buggy.
> > So it was all the (mis-) googled PS1 customizations,
> > that are actually incompatible with bash 3.2.0 and higher.
>
> This is just plain wrong in any bash version. Any part of the prompt that
> does not cause the cursor to change position needs to be protected inside
> \[ \]. Thus, the sequence from ESC to BEL on line 2 of your script should
> be inside \[ \].
>
> Using a CR (^M) probably screws things up as well. I don't even know why
> you have that in there. If you want to ensure the prompt always starts
> on a new line, use a newline instead of a CR, which will presumably
> start to overwrite the last line of the previous command's output, if
> that output doesn't end with a newline of its own. I would not expect
> this to be the desired behavior.
>
> In any case, you have a working prompt in your original email, so you
> could just stick with that one.
Yes. This was all the \[ \] , the lack of them.
They are bash-specific, and when the ^G^M works in mksh 52
(somehow not overwriting the previous command), it /looks/ like
pitfall of the former (which actually is a fast-rendering feature).
Nitpicked version control due to non-clean-room testing, therefore.
Re: [PATCH] Readline not being able to handle long lines
Sorry for splitting a message into two.
On Wed, Nov 30, 2016 at 07:34:25AM +0500, Mihail Konev wrote:
> On Tue, Nov 29, 2016 at 10:02:08AM -0500, Greg Wooledge wrote:
> > On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote:
> > > > Buggy (replace the ^-sequences in the second line):
> > > > PS1="[\${PWD##*/}]\$ " # set the prompt
> > > > PS1="^[]0;\$PWD^G^M$PS1"# set the window title
> > > >
> > >
> > > Turns out this was the only one buggy.
> > > So it was all the (mis-) googled PS1 customizations,
> > > that are actually incompatible with bash 3.2.0 and higher.
> >
> > This is just plain wrong in any bash version. Any part of the prompt that
> > does not cause the cursor to change position needs to be protected inside
> > \[ \]. Thus, the sequence from ESC to BEL on line 2 of your script should
> > be inside \[ \].
> >
> > Using a CR (^M) probably screws things up as well. I don't even know why
> > you have that in there. If you want to ensure the prompt always starts
> > on a new line, use a newline instead of a CR, which will presumably
> > start to overwrite the last line of the previous command's output, if
> > that output doesn't end with a newline of its own. I would not expect
> > this to be the desired behavior.
CR there cancels \e]0;
LF should indeed be used instead. But the 'bug' would still be there.
Just CR would not change the window title,
and just BEL would prevent both prompt and command being edited from
being displayed.
> >
> > In any case, you have a working prompt in your original email, so you
> > could just stick with that one.
>
> Yes. This was all the \[ \] , the lack of them.
>
> They are bash-specific, and when the ^G^M works in mksh 52
> (somehow not overwriting the previous command), it /looks/ like
> pitfall of the former (which actually is a fast-rendering feature).
The entire .bashrc config worked (after few edits), not just PS1.
And this made it look like bash was mibehaving.
>
> Nitpicked version control due to non-clean-room testing, therefore.
>
