Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

[Chet Ramey]

On 11/16/24 3:36 AM, Martin D Kealey wrote:


(Insert this between the "Copyright" and "Description" sections)


I don't think a disclaimer saying "this manual is not what it does not
claim to be" is particularly useful.

--
``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: bug-bash Digest, Vol 264, Issue 31

[Wiley Young]

ing 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.
>
> So, your process runs an empty command with a stdin redirection,
> which produces no output.  The procsub therefore receives no data.
> So the filename that the procsub is replaced by may as well be a symlink
> to /dev/null.
>
> Then, you have the command substitution with < followed by that
> filename, which contains no data.  The commsub produces no output,
> so it's replaced by nothing.  (The commsub is not quoted, so it
> simply vanishes, leaving echo with no arguments.)
>
> echo is executed with no arguments, so it writes a newline to stdout.
>
> If you expected the inner process substitution to generate output,
> then there needs to be a command of some kind inside it, and that
> command should write to stdout.  The obvious pick would be cat.
>
> In the *first* segment of code, your inner process substitution had
> the < command inside it, which acts like cat, because of a bash
> extension.  You're missing that in the final code segment.
>
>
>
> --
>
> Message: 3
> Date: Sat, 16 Nov 2024 18:52:12 -0800
> From: Wiley Young 
> To: bug-bash@gnu.org
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID:
>  7ru9dv702ixc8tdr-1...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> | From: Martin D Kealey
>
> |   "In the general case I agree; man
>
> | pages should be reference
>
> | manuals, not tutorials"
>
>   We should value others' contributions.
>   Most people, when they read something that they don't yet understand, if
> they wish to understand it, will seek out a more accessible text.
>   You lost me at "envisaged." Sorry, it didn't have anything to do medieval
> plate armor helmets.
>   Wiley
>
>
> --
>
> Message: 4
> Date: Sat, 16 Nov 2024 21:31:26 -0600
> From: "G. Branden Robinson" 
> To: bug-bash@gnu.org
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID: <20241117033126.jpjvaegplgvk55fw@illithid>
> Content-Type: text/plain; charset="utf-8"
>
> At 2024-11-16T18:52:12-0800, Wiley Young wrote:
> > | From: Martin D Kealey
> >
> > |   "In the general case I agree; man
> >
> > | pages should be reference
> >
> > | manuals, not tutorials"
> >
> >   We should value others' contributions.
>
> This statement implies that we lack a means of evaluating contributions.
>
> They either happen, or they do not, and they are all of equal value.
>
> In how many aspects of life do you apply this principle to human effort?
>
> >   Most people, when they read something that they don't yet understand,
> if
> > they wish to understand it, will seek out a more accessible text.
> >   You lost me at "envisaged." Sorry, it didn't have anything to do
> medieval
> > plate armor helmets.
>
> The dictionary you're using may be excessively recondite for you; seek
> out a more accessible one.
>
> Regards,
> Branden
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/bug-bash/attachments/20241116/5a0b2871/attachment.sig
> >
>
> --
>
> Message: 5
> Date: Sun, 17 Nov 2024 07:46:59 +0300
> From: Oğuz 
> To: "G. Branden Robinson" 
> Cc: "bug-bash@gnu.org" 
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID:
> <
> cah7i3lqw++ynnaqa5n2bkui-osev1nha0nquya8y_r3fjey...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sunday, November 17, 2024, G. Branden Robinson <
> g.branden.robin...@gmail.com> wrote:
> >
> > recondite
> >
>
> That's a recondite word, isn't it Sunday where you live?
>
>
> --
> Oğuz
>
>
> --
>
> Message: 6
> Date: Sat, 16 Nov 2024 23:56:59 -0500
> From: Lawrence Velázquez 
> To: "Mike Peters" 
> Cc: "Greg Wooledge" , bug-bash@gnu.org
> Subject: Re: redirection / process substitution fails to read a file
> descriptor
> Message-ID: <6d03bbcc-abc7-4056-97ba-962940876...@app.fastmail.com>
> Content-Type: text/plain
>
> On Sat, Nov

Re: bug-bash Digest, Vol 264, Issue 28

[Oğuz]

On Sunday, November 17, 2024, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:
>
> recondite
>

That's a recondite word, isn't it Sunday where you live?


-- 
Oğuz

Re: fg via keybind modifies tty settings

[#!microsuxx]

ah and to save and have it
copy it into .bash_profile or .profile

On Sat, Nov 16, 2024, 9:15 PM #!microsuxx  wrote:

> so , this is using the logic that vim returns a specific code 148 on
> control-z
> checking $? for it is what i did , for your request ..
>
> that thats a bit more clear , we can go on with testing
>
> copypaste the first small code in a terminal
> and proceed with vim c-z testing
>
> the second longer is only for when u wanna match that the 148 returned
> process for stty sane is 'vim*''
>
> i suggest u stick to the first small code and copy the bigger one for just
> so to have it
>
> greets
>
>
> On Sat, Nov 16, 2024, 7:52 PM David Moberg  wrote:
>
>> That looks very complicated, how do interpret that? And where/when to run
>> it?
>>
>> Den lör 16 nov. 2024 16:48#!microsuxx  skrev:
>>
>>> trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] &&
>>> bashcmd=$BASH_COMMAND ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd
>>> == vim* ]] && echo ye && stty sane '
>>>
>>> On Sat, Nov 16, 2024, 4:40 PM #!microsuxx  wrote:
>>>
 PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane '

 On Sat, Nov 16, 2024, 11:29 AM David Moberg  wrote:

> Ok, is there anything I can do on my user side to get desired behavior?
> (similar to running `stty sane` every time I send vim to the
> background.)
>
> Den tis 12 nov. 2024 16:49Chet Ramey  skrev:
>
> > 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.
> >
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> >  ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRUc...@case.edu
> http://tiswww.cwru.edu/~chet/
> >
>

Re: bug-bash Digest, Vol 264, Issue 28

[Wiley Young]

| From: Martin D Kealey

|   "In the general case I agree; man

| pages should be reference

| manuals, not tutorials"

  We should value others' contributions.
  Most people, when they read something that they don't yet understand, if
they wish to understand it, will seek out a more accessible text.
  You lost me at "envisaged." Sorry, it didn't have anything to do medieval
plate armor helmets.
  Wiley

Re: redirection / process substitution fails to read a file descriptor

[Greg Wooledge]

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 `<( be functionally equivalent to `<(<&3)`.


> Repeat-By:
> > echo foobar > test.txt
> > echo `< <( foobar

This is one of the most convoluted things I've seen in a long time.
You've got a command substitution with < as its command, which is
equivalent to $(cat ...) as a bash extension.  The argument of  > 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.

> > exec 3 > echo `< <(<&3)`
> 
> >

Here, you've got a process substitution with <&3 inside it.  I can
only guess what this is going to do.  It doesn't follow the standard
form of < filename which would be treated like cat filename, even though
it begins with a < character.

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.

So, your process runs an empty command with a stdin redirection,
which produces no output.  The procsub therefore receives no data.
So the filename that the procsub is replaced by may as well be a symlink
to /dev/null.

Then, you have the command substitution with < followed by that
filename, which contains no data.  The commsub produces no output,
so it's replaced by nothing.  (The commsub is not quoted, so it
simply vanishes, leaving echo with no arguments.)

echo is executed with no arguments, so it writes a newline to stdout.

If you expected the inner process substitution to generate output,
then there needs to be a command of some kind inside it, and that
command should write to stdout.  The obvious pick would be cat.

In the *first* segment of code, your inner process substitution had
the < command inside it, which acts like cat, because of a bash
extension.  You're missing that in the final code segment.

Re: bug-bash Digest, Vol 264, Issue 28

[G. Branden Robinson]

At 2024-11-16T18:52:12-0800, Wiley Young wrote:
> | From: Martin D Kealey
> 
> |   "In the general case I agree; man
> 
> | pages should be reference
> 
> | manuals, not tutorials"
> 
>   We should value others' contributions.

This statement implies that we lack a means of evaluating contributions.

They either happen, or they do not, and they are all of equal value.

In how many aspects of life do you apply this principle to human effort?

>   Most people, when they read something that they don't yet understand, if
> they wish to understand it, will seek out a more accessible text.
>   You lost me at "envisaged." Sorry, it didn't have anything to do medieval
> plate armor helmets.

The dictionary you're using may be excessively recondite for you; seek
out a more accessible one.

Regards,
Branden


signature.asc
Description: PGP signature

redirection / process substitution fails to read a file descriptor

[Mike Peters]

Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: darwin23.4.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC 
-DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/loc$
uname output: Darwin Mikes-Mac-Mini.local 23.3.0 Darwin Kernel Version 23.3.0: 
Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.$
Machine Type: aarch64-apple-darwin23.4.0

Bash Version: 5.2
Patch Level: 37
Release Status: release

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 `<( echo foobar > test.txt
> echo `< <( exec 3 cat <&3
foobar
> exec 3 echo `< <(<&3)`

>



Mike Peters

Re: redirection / process substitution fails to read a file descriptor

[Lawrence Velázquez]

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 `< <(> foobar

Be aware that <(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], 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

-- 
vq

Re: fg via keybind modifies tty settings

[David Moberg]

That looks very complicated, how do interpret that? And where/when to run
it?

Den lör 16 nov. 2024 16:48#!microsuxx  skrev:

> trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && bashcmd=$BASH_COMMAND
> ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd == vim* ]] && echo ye
> && stty sane '
>
> On Sat, Nov 16, 2024, 4:40 PM #!microsuxx  wrote:
>
>> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane '
>>
>> On Sat, Nov 16, 2024, 11:29 AM David Moberg  wrote:
>>
>>> Ok, is there anything I can do on my user side to get desired behavior?
>>> (similar to running `stty sane` every time I send vim to the background.)
>>>
>>> Den tis 12 nov. 2024 16:49Chet Ramey  skrev:
>>>
>>> > 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.
>>> >
>>> > --
>>> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>> >  ``Ars longa, vita brevis'' - Hippocrates
>>> > Chet Ramey, UTech, CWRUc...@case.edu
>>> http://tiswww.cwru.edu/~chet/
>>> >
>>>
>>

Re: fg via keybind modifies tty settings

[#!microsuxx]

so , this is using the logic that vim returns a specific code 148 on
control-z
checking $? for it is what i did , for your request ..

that thats a bit more clear , we can go on with testing

copypaste the first small code in a terminal
and proceed with vim c-z testing

the second longer is only for when u wanna match that the 148 returned
process for stty sane is 'vim*''

i suggest u stick to the first small code and copy the bigger one for just
so to have it

greets


On Sat, Nov 16, 2024, 7:52 PM David Moberg  wrote:

> That looks very complicated, how do interpret that? And where/when to run
> it?
>
> Den lör 16 nov. 2024 16:48#!microsuxx  skrev:
>
>> trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] &&
>> bashcmd=$BASH_COMMAND ' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd
>> == vim* ]] && echo ye && stty sane '
>>
>> On Sat, Nov 16, 2024, 4:40 PM #!microsuxx  wrote:
>>
>>> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane '
>>>
>>> On Sat, Nov 16, 2024, 11:29 AM David Moberg  wrote:
>>>
 Ok, is there anything I can do on my user side to get desired behavior?
 (similar to running `stty sane` every time I send vim to the
 background.)

 Den tis 12 nov. 2024 16:49Chet Ramey  skrev:

 > 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.
 >
 > --
 > ``The lyf so short, the craft so long to lerne.'' - Chaucer
 >  ``Ars longa, vita brevis'' - Hippocrates
 > Chet Ramey, UTech, CWRUc...@case.edu
 http://tiswww.cwru.edu/~chet/
 >

>>>

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

[Oğuz]

On Saturday, November 16, 2024, Martin D Kealey 
wrote:

> (Insert this between the "Copyright" and "Description" sections)
>
>
> *“PrefaceDear reader, if this is your introduction to the Shell programming
> language, please be aware that although it may look like other languages
> you are familiar with, such similarity is deceptive. The shell language is
> different in subtle and non-obvious ways from all (*1) other languages, and
> making assumptions based on what you know from other languages will lead
> you into traps. Please read the "Shell Grammar" section, allowing **time to
> digest it **slowly and thoroughly, and then read at least one of the
> recommended tutorials listed in appendix B. If you are unsure whether you
> fully understand the Shell, please take the test in appendix A.”*
>
>
> (Insert this after the "Bugs" section)
>
>
>
>
>
> *“Appendix A: a self-test to check understanding of basic principles.If you
> have trouble answering these questions then you should read one of the
> tutorials in Appendix B before consulting this manual. It will also be
> helpful to read the "Shell Grammar" section. Please write down your answer
> to each question, and then run its code (*2) to see if its behaviour
> matches your answer. There is no pass or fail mark, but any mismatch
> indicates that you would likely benefit from revision.*
> *1. What will be displayed when you run this: foo=bar ; echo zot | read foo
> ; echo "$foo"*
>
> *2. What will be displayed when you run this: export foo=bar ; foo=zot ;
> env | grep ^foo=*
> *3.  ...” *(additional questions welcome)
>
>
> *“Appendix B: Recommended TutorialsBefore consulting this manual, we
> recommend reading: https://mywiki.wooledge.org/BashGuide
>  *http://guide.bash.academy/*
> etc...
> We recommend avoiding the so-called Advanced Bash-Scripting Guide on *
> tldp.org 
> *...”*(additional reading suggestions welcome)
>
> -Martin
>
> (*1: yes I know it's an offshoot of the UNIX v7 shell, and other similar
> languages were designed around the same time, but they're all dead now, and
> certainly won't be encountered by a neophyte reading this manual page in
> 2024.)
>
> (*2: this may require some finessing of nroff to ensure that it does NOT
> substitute curly quotes or otherwise mess with the shell syntax, so that
> users can simply copy & paste the example code to test it)
>

This belongs in separate, unofficial document; not the reference manual,
which is fine as is.


-- 
Oğuz

Re: fg via keybind modifies tty settings

[#!microsuxx]

PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane '

On Sat, Nov 16, 2024, 11:29 AM David Moberg  wrote:

> Ok, is there anything I can do on my user side to get desired behavior?
> (similar to running `stty sane` every time I send vim to the background.)
>
> Den tis 12 nov. 2024 16:49Chet Ramey  skrev:
>
> > 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.
> >
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> >  ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRUc...@case.edu
> http://tiswww.cwru.edu/~chet/
> >
>

Re: fg via keybind modifies tty settings

[#!microsuxx]

trap ' t=$? ; [[ $BASH_COMMAND != *'$'bashcmd* ]] && bashcmd=$BASH_COMMAND
' debug ; PROMPT_COMMAND=' [[ $t == 148 && $bashcmd == vim* ]] && echo ye
&& stty sane '

On Sat, Nov 16, 2024, 4:40 PM #!microsuxx  wrote:

> PROMPT_COMMAND=' [[ $? == 148 ]] && stty sane '
>
> On Sat, Nov 16, 2024, 11:29 AM David Moberg  wrote:
>
>> Ok, is there anything I can do on my user side to get desired behavior?
>> (similar to running `stty sane` every time I send vim to the background.)
>>
>> Den tis 12 nov. 2024 16:49Chet Ramey  skrev:
>>
>> > 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.
>> >
>> > --
>> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
>> >  ``Ars longa, vita brevis'' - Hippocrates
>> > Chet Ramey, UTech, CWRUc...@case.edu
>> http://tiswww.cwru.edu/~chet/
>> >
>>
>

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

[Martin D Kealey]

On Sat, 16 Nov 2024 at 15:01, Robert Elz  wrote:

> Date:Sat, 16 Nov 2024 14:05:17 +1000
> From:Martin D Kealey 
> Message-ID:   d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com>
>
>   | I know, but "explicitly" is not the same as "highlighted", let alone
> "well
>   | enough".
>
> Please, nothing at all like you're suggesting.   Man pages are not, and
> not intended to be, tutorials.
>

In the general case I agree; man pages should be reference manuals, not
tutorials.

But in this case we have a language that simultaneously *looks* familiar,
but *actually* has an unfamiliar grammar, radically different semantics,
and a large number of intricate behind-the-scenes interactions. As a
result, some significant fraction of users are going to overestimate how
well they understand it, and prematurely skip from the "tutorial" phase to
the "reference manual" phase.

If nothing else, the manual needs to point out, in unequivocal ways that
cannot be missed, that they really *don't* understand it as well as they
think they do, and that they need to go study a tutorial before doing
anything else (and especially before submitting a bug report). And that
needs to be right up front, where they cannot miss it.

I would hope that this idea isn't controversial, but if you feel my idea
misses something important then please let me know. If you agree with the
idea, then I would welcome suggestions for improving the wording below,
which I offer as a tentative implementation of the idea above.

(Insert this between the "Copyright" and "Description" sections)


*“PrefaceDear reader, if this is your introduction to the Shell programming
language, please be aware that although it may look like other languages
you are familiar with, such similarity is deceptive. The shell language is
different in subtle and non-obvious ways from all (*1) other languages, and
making assumptions based on what you know from other languages will lead
you into traps. Please read the "Shell Grammar" section, allowing **time to
digest it **slowly and thoroughly, and then read at least one of the
recommended tutorials listed in appendix B. If you are unsure whether you
fully understand the Shell, please take the test in appendix A.”*


(Insert this after the "Bugs" section)





*“Appendix A: a self-test to check understanding of basic principles.If you
have trouble answering these questions then you should read one of the
tutorials in Appendix B before consulting this manual. It will also be
helpful to read the "Shell Grammar" section. Please write down your answer
to each question, and then run its code (*2) to see if its behaviour
matches your answer. There is no pass or fail mark, but any mismatch
indicates that you would likely benefit from revision.*
*1. What will be displayed when you run this: foo=bar ; echo zot | read foo
; echo "$foo"*

*2. What will be displayed when you run this: export foo=bar ; foo=zot ;
env | grep ^foo=*
*3.  ...” *(additional questions welcome)


*“Appendix B: Recommended TutorialsBefore consulting this manual, we
recommend reading: https://mywiki.wooledge.org/BashGuide
 *http://guide.bash.academy/* etc...
We recommend avoiding the so-called Advanced Bash-Scripting Guide on *
tldp.org 
*...”*(additional reading suggestions welcome)

-Martin

(*1: yes I know it's an offshoot of the UNIX v7 shell, and other similar
languages were designed around the same time, but they're all dead now, and
certainly won't be encountered by a neophyte reading this manual page in
2024.)

(*2: this may require some finessing of nroff to ensure that it does NOT
substitute curly quotes or otherwise mess with the shell syntax, so that
users can simply copy & paste the example code to test it)

Re: fg via keybind modifies tty settings

[David Moberg]

Ok, is there anything I can do on my user side to get desired behavior?
(similar to running `stty sane` every time I send vim to the background.)

Den tis 12 nov. 2024 16:49Chet Ramey  skrev:

> 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.
>
> --
> ``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/
>