Re: bash manual on interactive shell
Or maybe "started without non-option arguments, i.e. without a command or filename"? On Sun, Dec 12, 2021 at 11:51 PM Mallika wrote: > Hi! > > Thanks for the quick response! And for clearing up what 'option arguments' > means. > > I'm not sure I understood the last bit, though > >Something like "with only option arguments" could easily be misunderstood > as "with one or more option arguments". > > Are you saying that the 'only' could be easily ignored? i.e. "with one or > more option arguments" is incorrect because it fails to specify that *no* > non-option arguments may be used? > Oh! You're saying the language used includes the case of no arguments at > all, whereas the language I'm proposing may be interpreted as requiring > option-arguments (which is what I had strugglingly understood it to mean) > in that case, may I simply suggest: > "started without any arguments, or with option arguments only" > > It is certainly more words, but unless you already have a solid > understanding of non-option arguments (commands?) - in which case you're > only having to perform one negation in your head - I think this > construction makes it significantly easier to follow along. > > Ultimately, of course, it's up to you. I've made as much of a case for > re-wording as I could :) > > Thank you again for your help, > Mallika > > > On Sun, Dec 12, 2021 at 10:08 PM Lawrence Velázquez wrote: > >> On Sun, Dec 12, 2021, at 9:03 PM, Mallika wrote: >> > I'm a little confused about how all the and's and or's combine (I >> suppose >> > it's obvious if you're a little more familiar with the material - but it >> > would be great if it were possible to express this by indentation), >> >> It's a relatively confusing state of affairs. An unordered list >> might help. >> >> > but I'd actually decided to write in just to clarify that first line: >> > "started without non-option arguments," >> > >> > Does "option arguments" mean "option*al* arguments"? >> >> No. While all option arguments happen to be optional, not all >> optional arguments are options. >> >> An "option argument", roughly speaking, is an argument that begins >> with one or two hyphen-minuses and affects the configuration of the >> invoked shell. They are described here: >> >> https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html >> >> > If the double-negative* is *actually correct, wouldn't the same >> sentiment >> > be expressed by "started with only option(al?) arguments"? >> Double-negatives >> > are inherently confusing, so it would be helpful to avoid them. >> >> Something like "with only option arguments" could easily be >> misunderstood as "with one or more option arguments". >> >> -- >> vq >> >
Re: bash manual on interactive shell
On Mon, Dec 13, 2021 at 8:31 AM Mallika wrote: > "An interactive shell is one started without non-option arguments, unles*s* > -s is specified, without specifying the -c option, and whose input and > error output are both connected to terminals (as determined by isatty(3)), or > one started with the -i option." > > I'm a little confused about how all the and's and or's combine (I suppose > it's obvious if you're a little more familiar with the material - but it > would be great if it were possible to express this by indentation), > > but I'd actually decided to write in just to clarify that first line: > "started without non-option arguments," > > Does "option arguments" mean "option*al* arguments"? > If so, is the statement even correct? i.e. should it not be > "started without optional arguments"? It says "non-option" arguments; in other words, arguments that aren't options. > > If the double-negative* is *actually correct, wouldn't the same sentiment > be expressed by "started with only option(al?) arguments"? Double-negatives > are inherently confusing, so it would be helpful to avoid them. No. An "option argument" would be an argument that follows an option, such as `extglob' in `bash -O extglob'. That sentence is not about them. As to what non-option arguments are, all arguments in `bash file command_name positional_parameters' are non-option arguments, so are command name and positional parameters in `bash -s command_name positional_parameters'; but the former starts a non-interactive shell, and the latter starts an interactive shell since `-s' is specified. > > -Mallika
Re: bash manual on interactive shell
On Sun, 12 Dec 2021 23:51:22 -0800 Mallika wrote: > Hi! > > Thanks for the quick response! And for clearing up what 'option arguments' > means. > > I'm not sure I understood the last bit, though > >Something like "with only option arguments" could easily be misunderstood > as "with one or more option arguments". > > Are you saying that the 'only' could be easily ignored? i.e. "with one or > more option arguments" is incorrect because it fails to specify that *no* > non-option arguments may be used? > Oh! You're saying the language used includes the case of no arguments at > all, whereas the language I'm proposing may be interpreted as requiring > option-arguments (which is what I had strugglingly understood it to mean) > in that case, may I simply suggest: > "started without any arguments, or with option arguments only" Just to muddy the waters further, the POSIX Utility Syntax Guidlines [1] employs a different terminology. What the bash manual refers to as a "non-option argument" is, instead, an "operand". On the other hand, an "option-argument" (note the hypen) would be defined as the argument that follows an option that expects one. For instance, in the case of `sh -c date`, the string, "date", would be an option-argument! In the absence of a formal definition, the import of any term constitutes a form of tribal knowledge. While the GNU glibc manual speaks of "non-option arguments" in its Program Argument Syntax Conventions [2], it does, unfortunately, lack the formality and rigour of the aformentioned POSIX document. Still, one can infer the meaning by also considering its first bullet point, not that I would expect anyone reading the bash manual to necessarily think of looking there. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html [2] https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html > > It is certainly more words, but unless you already have a solid > understanding of non-option arguments (commands?) - in which case you're > only having to perform one negation in your head - I think this > construction makes it significantly easier to follow along. > > Ultimately, of course, it's up to you. I've made as much of a case for > re-wording as I could :) You mentioned being confused by how the and's and or's combine. The wording of the bash man page seems marginally less ambiguous in that regard, partly owing to its sparse use of the comma. "An interactive shell is one started without non-option arguments (unless -s is specified) and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option." Although, I would say that the absence of a comma before whose is a grammatical error. In any case, I wanted to suggest the use of the word, either. For example:- "An interactive shell is either one started without non-option arguments (unless -s is specified) and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option." I think that the addition of this word might increase the probability of the sentence being (correctly) interpreted in the fashion of "an interactive shell is either one that fulfils ( criteria A ) or ( criteria B )", keeping in mind that the -i option always renders bash interactive. -- Kerin Millar
Re: can't unset hash item with specific key
On 12/12/21 2:47 PM, l.bash...@scarydevilmonastery.net wrote: > Bash Version: 5.1 > Patch Level: 12 > Release Status: release > > Description: > making left square bracket char ([) part of the key into a hash causes > unset to silently fail when trying to unset that specific hash item. > The position of left square bracket char in the string used as key > doesn't > matter. unset also fails when the key is a single [ character. > Please refer to the following script which attempts to demonstrate this > quirk. Thanks for the report. This has been discussed a number of times in the past, most recently as part of a long thread about reworking array expansion in general and `unset' in particular: https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html (the thread extends into April: https://lists.gnu.org/archive/html/bug-bash/2021-04/msg8.html) In this case, the `assoc_expand_once' option does not help; even the successive layers of quoting don't prevent the `]' from being considered the end of the subscript, complicated by the fact that the argument to `unset' undergoes a set of word expansions before unset even sees it. The general workaround for this is to store the key in a variable and rely on the variable expansion to produce the right subscript without the `]' being mistaken for the subscript terminator. As a result of the discussion from March/April, the devel branch uses a different strategy that results in the `unset' working in all of the examples where the argument can be recognized as a valid array subscript reference before it's expanded, and all the other examples you gave except the ones that leave the `]' unquoted (the reason for which should be easy to figure out). Chet -- ``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/
Re: `${array[index]=value}' broken in devel
On 12/13/21 2:36 AM, Oğuz wrote:
> To reproduce:
>
> $ a=()
> $ echo ${a[42]=foo}
> Desktop Documents Downloads mpv-shot0001.jpg Music Pictures Public
> Videos VirtualBox VMs
> $ declare -p a
> declare -a a=([42]="foo")
>
> or
>
> $ declare -A a
> $ echo ${a[foo]=bar}
> P�ϝU
> $ declare -p a
> declare -A a=([foo]="bar" )
Thanks for the report.
--
``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/
