Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
On Monday, November 18, 2024, Martin D Kealey wrote: > > That's valid, but how else do we get people to read the correct document > for their skill level, How is it our responsibility? > I've used Bash for about 30 years, and even I have to wonder whether the > Shell manual should start with this warning instead: > > " > *If you're writing a new script from scratch, STOP NOW, and go and choose a > different language - ANY language. No matter what you choose, it will be a > better choice than the Shell language.* > Maybe it's time "you" switched shells and stop bothering "us". -- Oğuz
Re: fg via keybind modifies tty settings
On Sun, 17 Nov 2024 at 04:52, David Moberg wrote:
> That looks very complicated, how do interpret that? And where/when to run
> it?
>
To me this seems to have taken a wrong turn before the question was even
asked.
Just because readline has a "run a command" mode does NOT mean it's
necessarily the appropriate way to invoke the 'fg' command. As clearly
shown in the manual, there's a whole bunch of stuff around bind -x that's
intended to support invoking a command *as a way to do specialised editing
within the command line.*
This is clearly *not* "editing within the command line", so just do it the
old fashioned way, with a macro:
bind -m emacs '"\C-_":"\C-e\C-ufg\n"'
bind -m vi '"\C-_": "ddafg\C-j"'
bind -m vi-insert '"\C-_":"\e0Cfg\n"'
(Choose your own preferred key instead of ctrl-_ of course)
These all do the same thing in different input modes: erase the current
line, then type "fg" and enter it. (If you actually want to keep the text
that was in the edit buffer, you can just paste it back in at the next
prompt; ctrl-Y ("yank") in emacs mode, and p or P ("put") in vi mode.)
-Martin
Re: redirection / process substitution fails to read a file descriptor
Date:Sun, 17 Nov 2024 12:16:40 -0600 From:Mike Peters Message-ID: | * (Although I have yet to determine any purpose or significance of | these redirections in the manual, other than simply not causing an error, | as it "do[es] not affect the current shell environment", and there is | "no command name", so what is there remaining to affect?) The short answer is side effects. This is more obvious in the >file case, as that causes file to be created (if needed) and truncated (if it didn't need to be created) or >>file which causes file to be created if needed (but not truncated). The use for testing for errors is also occasionally useful - a redirection error will cause the shell to exit (non-interactive shell) so &2 message; exit 2; } (or similar) (and output directions test that the file either exists or can be created, and is writeable). Most of the time commands with nothing but redirections aren't useful, but occasionally they can be (>file is faster than cp /dev/null file, so if a script is wanting to make large numbers of empty files, just using redirections to do it can be useful). kre
Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command
On Sun, 17 Nov 2024, 03:32 Chet Ramey, wrote: > On 11/16/24 3:36 AM, Martin D Kealey wrote: > I don't think a disclaimer saying "this manual is not what it does not > claim to be" is particularly useful. > That's valid, but how else do we get people to read the correct document for their skill level, when their self-assessment will invariably be wrong? How can we reasonably expect users to assess their own skill level and choose a 'tutorial' when their instincts are telling them "yep I understand almost all of this stuff"? The Shell language *looks* simple, while actually being one of the most complex languages in common use, and its multitude of subtle fishhooks effectively turns half the populace into Dunning-Kruger sufferers. Moreover, we are complicit in this: every new feature added to Bash makes it more useful, more attractive to new users. The morally right thing to do would be to shoo them away, not attract them. In the meantime we owe them a duty of care. I've used Bash for about 30 years, and even I have to wonder whether the Shell manual should start with this warning instead: " *If you're writing a new script from scratch, STOP NOW, and go and choose a different language - ANY language. No matter what you choose, it will be a better choice than the Shell language.* *The Shell language makes bad coding easy, and good coding hard, so almost everything you write will turn out to have bugs that may lurk for years before biting you - or your successor.** It lacks sane error handling. It lacks sane variable scopes. It lacks data structures. It lacks modules. It looks like other languages, but doesn't behave like them.* *And in case you're wondering, no, Bash can't be changed to make a saner language, because it has to meet the POSIX standard, as well as 40 years of backwards compatibility.* *Don't say we didn't warn you.* *(But don't simply choose a different implementation of the Shell; that would be worse.)*" -Martin >
Re: redirection / process substitution fails to read a file descriptor
On 2024-11-16 20:35, Greg Wooledge wrote: On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote: Description: Process substitution does not generate properly when pulling from another file descriptor, although it works when pulling from a file directly. In the below sample shell session, it is expected that `<( Repeat-By: > echo foobar > test.txt > echo `< <( This is one of the most convoluted things I've seen in a long time. Evidently I overlooked a further simplification I could have made for this example when converting the commands I was playing around with to test what works and what doesn't. * > exec 3 cat <&3 foobar OK. This part is straightforward. Note that you used a command, cat, to write output. You didn't simply type <&3 without a command. You're saying that <&3 on an input line by itself should work? It outputs nothing for me. Effectively the same point as the purpose of this submission. Although > exec 3 echo `< <(<&3)` > I'm guessing that the parser sees the <& and decides *not* to treat this as a shortcut of cat with &3 as a filename. Therefore, the only thing the parser can do is treat this as an empty command with a <&3 redirection attached to it. This is the clarification I needed, in which I was under a mistaken impression of the cat shortcut working also for file descriptors. Thank you. * FWIW, this is what I was developing when I came upon the issue: exec 3>&1 # save the monitor exec 4>all.txt # generate single entry point for output # otherwise output may not be in order exec 1> >(tee out.txt /dev/fd/4 >&3) # out everywhere exec 2> >(tee err.txt /dev/fd/4 >&3) # err everywhere echo "session output..." echo "session problems..." >&2 exec 6>&1 1>&3 6>&- # restore stdout exec 6>&2 1>&3 6>&- # restore stderr exec 4>&- # close all.txt Mike Peters
Re: redirection / process substitution fails to read a file descriptor
On 2024-11-16 22:56, Lawrence Velázquez wrote: On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote: On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote: Description: Process substitution does not generate properly when pulling from another file descriptor, although it works when pulling from a file directly. In the below sample shell session, it is expected that `<( Repeat-By: > echo foobar > test.txt > echo `< <( Be aware that <( I don't know what documentation it was missing from, but this usage is consistent and logically valid with the manual... Process substitution 'takes the form of <(list) or >(list)'. The grammar defines 'list' to be 'a sequence of one or more pipes', a 'pipeline' to be 'a sequence of one or more commands'. Command substitution takes the form $(command) or `command`, and since ` However, the "issue" does affect command substitutions: $ echo foobar >test.txt $ echo "$(https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=d3e86e66ce857a8dc02e3116fd98b6e5b34d6364 [2] https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00045.html I'm guessing that the parser sees the <& and decides *not* to treat this as a shortcut of cat with &3 as a filename. Therefore, the only thing the parser can do is treat this as an empty command with a <&3 redirection attached to it. As I understand the code [3][4], Agreed. I had a mistaken understanding. I took too much liberty in interpretation. This reading doesn't make much sense: The command substitution $(cat &n) can be replaced by the equivalent but faster $(< &n). There might be an argument for it if the documentation read: The command substitution $(cat I disagree. The REDIRECTION section of the manual uses the word 'word' when it might refer to either a file descriptor or a file, so I think "there might be an argument" if the declaration involved incorporating 'word' in place of 'file'. [3] https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/evalstring.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n198 [4] https://git.savannah.gnu.org/cgit/bash.git/tree/make_cmd.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n663 Mike Peters
Re: redirection / process substitution fails to read a file descriptor
On Sun, Nov 17, 2024 at 12:16:29 -0600, Mike Peters wrote: > On 2024-11-16 20:35, Greg Wooledge wrote: > > On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote: > > > > exec 3 > > > cat <&3 > > > foobar > > > > OK. This part is straightforward. Note that you used a command, cat, > > to write output. You didn't simply type <&3 without a command. > > You're saying that <&3 on an input line by itself should work? It outputs > nothing for me. Effectively the same point as the purpose of this submission. > Although > > > exec 3 > > > echo `< <(<&3)` Which is why it didn't work here -- there's no cat command. There's no command at all.
Re: redirection / process substitution fails to read a file descriptor
On Sun, Nov 17, 2024, at 1:16 PM, Mike Peters wrote: > On 2024-11-16 22:56, Lawrence Velázquez wrote: >> Be aware that <(> Emanuele brought it up [2]; it will not work in future releases. > > I don't know what documentation it was missing from, but this usage is > consistent and logically valid with the manual... Process substitution > 'takes the form of <(list) or >(list)'. The grammar defines 'list' to > be 'a sequence of one or more pipes', a 'pipeline' to be 'a sequence of > one or more commands'. Command substitution takes the form $(command) > or `command`, and since ` shortcut, EXPANSION explicit allows redirections*: "If no command name results, > redirections are performed, but do not affect the current shell > environment." Thus the manual's grammar technically does document the > validity of <( I hope it's removal is documented in the manual. The removed behavior was not documented to begin with. >> There might be an argument for it if the documentation read: >> >> The command substitution $(cat > the equivalent but faster $(> >> But it doesn't. >> > > I disagree. The REDIRECTION section of the manual uses the word 'word' > when it might refer to either a file descriptor or a file, so I think > "there might be an argument" if the declaration involved incorporating > 'word' in place of 'file'. That wouldn't really make a difference. The important changes would be adding a redirection to the first substitution and removing the space from the second. A simple "file"/"word" swap wouldn't justify the confusion... The command substitution $(cat word) can be replaced by the equivalent but faster $(< word). ...since $(cat &3) and $(< &3) are still nonsense. (Also, in the manual "&n" is never a valid substitution for "word".) -- vq
Re: fg via keybind modifies tty settings
On Wed, 13 Nov 2024 at 01:49, Chet Ramey wrote: > On 11/10/24 7:14 PM, Martin D Kealey wrote: > > > Perhaps what's really needed is to make sure that "ordinary" commands > bound > > using bash -x are completely broken (so people won't try to use them), > > rather than almost working. > > `Ordinary' commands aren't broken. Programs like vim that modify the > terminal settings, which are in the minority, are. > Fixing things for 'vim', will likely break them for me. That's why I'm suggesting that there needs to be two separate ways of "binding an invocable command". For many commands it won't matter which one you use, but for I have a use case where I do NOT want the stty settings to be restored after running a command from a key binding, because it would defeat the point: bind -x '"\C-_": stty tostop' This enables me to hit ctrl-7 (same key as '&') to temporarily turn on TOSTOP in termios.c_lflags, to prevent the output of a background command from messing up the line I'm currently editing (and vice versa). (The choice of key or escape sequence isn't important; it's the effect of stty that matters.) Currently it only lasts as long as it takes me to type the current command, which is useful but not critical. Here's an example transcript; please take note of the timestamps in the prompt: > 11:47:44 3$ bind -x '"\C-_": stty tostop' > 11:48:02 4$ stty -a | grep -o .tostop > -tostop > 11:51:11 5$ (sleep 5 ; echo Hello)& > [1] 21951 > 11:51:25 6$ echo Hi* # at this point I hit ctrl-7 and then wait a while > before hitting enter; note the absence of intermingling* > Hi > > [1]+ Stopped ( sleep 5; echo Hello ) > 11:51:35 7$ bg > [1]+ ( sleep 5; echo Hello ) & > Hello > [1]+ Done( sleep 5; echo Hello ) > 11:51:38 8$ stty -a | grep -o .tostop > -tostop > -Martin
