Re: degraded error message in case of hash-bang interpreter error
Date:Mon, 4 Nov 2024 19:30:23 +1000 From:Martin D Kealey Message-ID: | I guess I should s/POSIX/common Unix-like tradition/ and maybe | mumble something about BSD. Yes, but this would not be the place where it is appropriate to request system call changes - what do you expect bash developers (or users in general) to do that could alter anything there. Instead you'd need to go to *every* OS that exists (at least the ones bash runs on for this purpose - which I think includes Windows) and convince them to change the way things work, to meet your demands. Good luck with that. kre
Re: degraded error message in case of hash-bang interpreter error
On 11/3/24 10:45 PM, Martin D Kealey wrote: This is one of those cases I would file under "POSIX being annoyingly literal". POSIX says that the execve syscall reads the name of an interpreter (and options) from a '#!' line, prefaces them onto the front of argv, and then restarts itself. This is why some people argue that ENOENT is "logical" the interpreter can't be found. (And to be fair, Linux seems to apply this to / any/ missing "interpreter", including the ELF loader.) It doesn't. You have to deal with what the implementations return and make your best guess. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash -xv issue with stderr
On 11/4/24 3:20 AM, Christoph Zimmermann wrote: Hi Chat, As I can't seem to find this: You are referring to the 'devel' branch at https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? What is that? I am referring to the bash git repository at http://git.savannah.gnu.org/cgit/bash.git/?h=devel -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash -xv issue with stderr
Thanks for pointing me in the right direction. When checking the info and man (bash.1) files on the devel branch of this repo, I can't find the reference you and other people pointed out wrt to the clarification I referred to earlier. Perhaps you could point me in the right direction as apparently I'm missing something? Thanks! On 04.11.24 16:03, Chet Ramey wrote: On 11/4/24 3:20 AM, Christoph Zimmermann wrote: Hi Chat, As I can't seem to find this: You are referring to the 'devel' branch at https:// github.com/bminor/bash (files doc/bash.info and doc/bash.1)? What is that? I am referring to the bash git repository at http://git.savannah.gnu.org/cgit/bash.git/?h=devel -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash -xv issue with stderr
On 11/4/24 10:15 AM, Christoph Zimmermann wrote: Thanks for pointing me in the right direction. When checking the info and man (bash.1) files on the devel branch of this repo, I can't find the reference you and other people pointed out wrt to the clarification I referred to earlier. http://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?h=devel&id=bf093e31aec6963c44309274e8ec5b8eca05af95 Around line 11304. .TP 8 .B \-x After expanding each \fIsimple command\fP, \fBfor\fP command, \fBcase\fP command, \fBselect\fP command, or arithmetic \fBfor\fP command, display the expanded value of .SM .BR PS4 , followed by the command and its expanded arguments or associated word list, to the standard error. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: degraded error message in case of hash-bang interpreter error
On Mon, 4 Nov 2024, 21:37 Robert Elz, wrote: > | I guess I should s/POSIX/common Unix-like tradition/ and maybe > | mumble something about BSD. > > you'd need to go to *every* OS that exists … Good luck with that. Yeah I'm well aware this is futile whimsy. I should have raised this point about 40 years ago. -Martin
Re: bash -xv issue with stderr
On Mon, Nov 4, 2024 at 3:21 AM Christoph Zimmermann wrote: > > As I can't seem to find this: https://git.savannah.gnu.org/git/bash.git
Re: [PATCH] lib/readline/doc makefiles clean targets
On Sun, Nov 03, 2024 at 03:28:27PM -0500, Chet Ramey wrote: > On 11/1/24 6:20 PM, Mike Jonkmans wrote: > > On Fri, Nov 01, 2024 at 01:25:46PM -0400, Chet Ramey wrote: > > > On 10/29/24 1:04 PM, Mike Jonkmans wrote: > > > > Hi Chet et al., > > > > > > > > If I run, on devel (4917f285): > > > > - ./configure > > > > - make > > > > - make clean > > > > - git status > > > > > > > > I would expect to see nothing special. > > > > Instead: > > > > a) a whole bunch of files got deleted in lib/readline/doc. > > > Yeah. Those files aren't part of the bash distribution, and so they get > > > cleaned. I left them there the last couple of pushes because I wanted > > > people to get a look at the documentation updates I made. It was easier > > > for me than splitting the files between the bash and readline devel > > > branches. > > Ok, i see. > > Sort of a problem is, that these files aren't explicitly made by make. > They are. Unless you mean the intermediate files created by running tex > to make the dvi files. I see you pushed some changes here, nice. > > According to info (make)Standard Targets, we should have: > > mostlyclean < clean < distclean < maintainer-clean > That hierarchy isn't gospel. Agreed, but... > The current Makefile rules are fine. There are some issues though. Some less important. 1) After 'make distclean', it doesn't build: some .o files need y.tab.h. 2) The use of recursive make, makes it harder to do dependencies right; 2a) Building outside of the source tree does not have proper deps; 3) The various Makefiles disagree on 'clean: mostlyclean' versus 'mostlyclean: clean'; 4) .PHONY is not used for the sub-makes *clean rules; 5) git (status), .gitignore and make are disconnected; 6) There is redundancy/duplication in the actions of various rules; 6) Same for the definitions of variables. > > (One could argue, whether the devel branch is a distribution.) > It's not. It's a snapshot of ongoing work. As such, it has the purpose of: - bringing in early fixes/patches; - communicating future changes, eliciting comments. So the devel branch should be easy to work with for outsiders. That, in my opinion, would warrant more adherence to the standard make targets. It doesn't need to be religious, perhaps stating deviations and/or documenting what the expectations are on the various make-targets. INSTALL already has some text. Are you often building from devel yourself? As maybe a check, in git, on a push to devel, would be nice to have. Anyway, I suppose that for the clean-targets (not maintainer-clean) git restore .; configure; make `clean-target' should see no deleted/modified files in 'git status'. This currently is not the case for mostlyclean and distclean. > > Would you accept patches for: > > a) reversing mostlyclean/clean; > > b) rewrite mostlyclean/clean/distclean as described; > > c) rewrite maintainer-clean so that it reuses the other clean-targets. > I can make the appropriate changes, you don't need to send patches. Not doing things, I can do that ;) > > I guess that config.h, buildconf.h etc. - products of running configure > > or config.status - are 'files recording the configuration'. > > Thus should be exempt from 'make clean mostlyclean'. > They already are. Correct. I was merely wondering what 'files recording the configuration' means. That could also be interpreted as only config.status, not the files generated from the various *.in files. Misc notes - examples/loadables/Makefile(.in) has no mostlyclean target. The error is ignored, but clutters the output. - 'make mostlyclean' removes doc/bashref.* and doc/Makefile. No recovery, must run 'git restore doc; configure'. - in doc/Makefile: the maybe-clean test should use realpath (cd ...; pwd -P) -- Regards, Mike Jonkmans
Re: bash -xv issue with stderr
i doubt its 'bminor' he talks about bash git on savannah .. i think .. On Mon, Nov 4, 2024, 09:21 Christoph Zimmermann wrote: > Hi Chat, > > As I can't seem to find this: You are referring to the 'devel' branch at > https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? > > Cheers, Chris > > On 03.11.24 21:00, Chet Ramey wrote: > > On 11/3/24 5:28 AM, Christoph Zimmermann wrote: > >> Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which > >> unfortunately does require a CB change). > >> > >> If this is intended behaviour, it should be clearly documented on the > corresponding man > >> page (which doesn't seem to be case ATM). > > > > The current devel branch man page and info file both specify that the > > xtrace output is written to stderr. > > > > -- > This email account is monitored seven days a week. > >
Re: bash -xv issue with stderr
Hi Chat, As I can't seem to find this: You are referring to the 'devel' branch at https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? Cheers, Chris On 03.11.24 21:00, Chet Ramey wrote: On 11/3/24 5:28 AM, Christoph Zimmermann wrote: Thanks for all the quick reactions on that issue (including microsuxx's suggestion which unfortunately does require a CB change). If this is intended behaviour, it should be clearly documented on the corresponding man page (which doesn't seem to be case ATM). The current devel branch man page and info file both specify that the xtrace output is written to stderr. -- This email account is monitored seven days a week. OpenPGP_0xE7EEC1C45FE2A7BB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: degraded error message in case of hash-bang interpreter error
Fair point. I guess I should s/POSIX/common Unix-like tradition/ and maybe mumble something about BSD. On Mon, 4 Nov 2024, 17:54 Robert Elz, wrote: > Date:Mon, 4 Nov 2024 06:55:54 +0300 > From:=?UTF-8?B?T8SfdXo=?= > Message-ID: < > cah7i3lrjfhfgcejhmrmwd7mu2hu4r_oumvszw3esrc+3xqg...@mail.gmail.com> > > | On Monday, November 4, 2024, Martin D Kealey > | wrote: > | > | > POSIX says that the execve syscall reads the name of an interpreter > (and > | > options) from a '#!' line, > | > > | > | Where? > > Good question. While POSIX has (just barely) reached beyond the point of > believing > that #! does not exist (which it used to try and pretend for a long time) > it still > resolutely avoids spexifying anything at all about how it works, or what > it does, > when it does appear. In fact it goes so far as to demand that a strictly > conforming > shell script must not have '#!' as its first two characters (even though > the '#' there > would normally just indicate a comment up to the next \n) as it is not > specified > how a script that starts with #! is processed. > > kre > >
Re: fg via keybind modifies tty settings
Den ons 16 okt. 2024 17:43Chet Ramey skrev: > On 10/13/24 12:10 PM, David Moberg wrote: > > A new issue popped up with these changes. After second time of suspend > and > > foreground with binding, the tty will not react to control keys but > instead > > print them on the prompt. > > In general, this can't work, given a well-behaved process like vim that > modifies the tty settings. > > > | start vim > >ctrl-z (to suspend) > >ctrl-a (bound to `fg` to bring to foregound) > >ctrl-z (to suspend a 2nd time) > ># broken state (but I dont see anything changed in the output of `stty > > -a`) > ># ctrl-a prints ^A (instead of executing fg) > ># prints ^[[A (Instead of invoking history) > > > > Issue 1: control codes are printed to prompt > > The important thing to remember is that the shell saves the tty settings > when it starts up and after each forked command exits, so it can set them > for child processes. This is how it can make stty settings stick while > still setting the terminal for readline. It doesn't do this if it's running > a command from a readline key binding. > > It restores the terminal attributes to these saved settings after a process > exits due to a signal or stops so a misbehaving process doesn't corrupt > the terminal. > > Let's use the following shorthand: > > R = tty settings for readline (-icanon) > V = tty settings for vim (-icanon) > S = tty settings shell inherited or saved (icanon) > > Here's what happens: > > shell saves tty settings S > readline sets tty settings R > readline reads "vim ...\n" > shell sets tty to S > shell execs vim > vim saves tty settings S > > vim sets tty settings V > vim reads ^Z > vim sets tty settings S (saved) > > vim sends itself SIGTSTP > shell catches stopped child > > shell sets tty settings S (the saved tty settings because the process > stopped) > readline sets tty settings R > readline reads ^A > shell sends SIGCONT due to running `fg' from the `bind -x' binding > - this is where the shell used to save the terminal settings again > for later resetting, but it no longer does due to your previous > report, so S is unchanged > > vim gets SIGCONT > vim sets tty settings V > vim reads ^Z > vim sets tty settings S (saved) > > vim sends itself SIGTSTP > shell catches stopped child > > shell sets tty settings S (saved tty settings because the process stopped) > - but it wouldn't matter because vim already set them to S > > readline is still active because this was all a key binding > > Now readline thinks the settings are R, but the settings are S. > > > > Issue 2: typing `echo` tab completes correctly to `echo`, but this > > debug print is printed: > > ``` > > bash: DEBUG warning: cpl_reap: deleting 33287 > > That's a red herring, the programmable completion you're using uses a > coprocess. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ So there is no good way of solving this and therefor no way to solve it at all? I guess fish and zsh might be misbehaving in other ways, but they seem to handle this detail better. I wonder what the tradeoff is.
