Date:Sat, 18 May 2024 23:00:41 +
From:Matheus Afonso Martins Moreira
Message-ID:
| If you resolve the path, you're just reinventing the source builtin.
Nonsense, the real work of the source ('.' really) utility is to
read the file, parse it, and execute it.
Date:Sat, 18 May 2024 08:39:57 -0300
From:Matheus Afonso Martins Moreira
Message-ID:
| As the user, it should be my prerogative to set the
| variable on my environment and/or rc so that I can
| organize my sourceable scripts however I want
Of course. The
Date:Fri, 17 May 2024 12:57:25 -0400
From:Grisha Levit
Message-ID: <20240517165738.8896-1-grishale...@gmail.com>
| The current cmp implementation for size and blocks subtracts the two
| values and returns the difference as an int. This subtraction can
|
Date:Fri, 17 May 2024 10:20:57 -0400
From:Chet Ramey
Message-ID:
| If you set the variable to something that needs it, you have to accept
| the stat overhead -- otherwise, how could it do what you've requested?
Of course, I understand that, I'm just not sure
Date:Fri, 17 May 2024 10:09:06 -0400
From:Chet Ramey
Message-ID:
| If you don't want `.' to search $PATH, turn off the `sourcepath' shell
| option.
That part I assumed was already taken care of (that is, would be) just
by use of the BASH_SOURCE_PATH variable.
Date:Thu, 16 May 2024 23:54:12 -0400
From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?=
Message-ID: <0b3fa8d4-7a3f-4bd6-8e8d-f7d1746be...@app.fastmail.com>
| This is the description from the bash.1 that's currently in my local
| repository:
Thanks.
Possibly useful I
Date:Thu, 16 May 2024 11:36:50 -0400
From:Chet Ramey
Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>
| You can already do this; there's no reason to add these semantics to a
| variable setting.
How? What I'm looking for is a way to catch accidental
Date:Wed, 15 May 2024 11:03:12 -0400
From:Chet Ramey
Message-ID:
| That assumes a flat directory structure for the script and its associated
| files, correct? How common is that really? Or is it more common to have
| something like the script in somewhere/bin,
Date:Wed, 15 May 2024 09:19:06 -0400
From:Chet Ramey
Message-ID: <86e381d8-dc83-4ef8-90e6-122468fa4...@case.edu>
| Why make it different from other PATH-like variables, where a null
| component is equivalent to "."?
Because having two ways to do the same thing
Date:Tue, 14 May 2024 15:51:10 -0400
From:Chet Ramey
Message-ID:
| What do folks think about forcing an option to enable using
| BASH_SOURCE_PATH? Should it be required? Is it necessary? (I personally
| think it is not.) We discussed this briefly last week but
Date:Mon, 6 May 2024 23:01:16 +0900
From:Koichi Murase
Message-ID:
| Hmm, maybe you mean that a shell is free to anytime remove the
| terminated foreground jobs from the list regardless of whether it has
| been reported or not, and "all jobs whose ...
Date:Fri, 3 May 2024 09:18:09 -0400
From:Chet Ramey
Message-ID: <842de6ec-c7f9-47fb-ab21-e25c0bfd8...@case.edu>
| How is this any different than
|
| PATH=$BASH_IMPORT_PATH:$PATH source
| or
| PATH=$BASH_IMPORT_PATH source
|
| You could force the latter
Date:Fri, 3 May 2024 13:11:00 -0400
From:Chet Ramey
Message-ID:
| >> ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID )
| >
| > Never seen this and it's ugly too. Oh well, at least it doesn't show
| > the expanded arguments.
|
| It's been
Date:Thu, 2 May 2024 12:17:36 -0400
From:Chet Ramey
Message-ID:
| It's the reporting part we're talking about here, not the removing.
Should be effectively the same thing for the jobs in question (which
aren't ones that are stopping) - when a terminated job is
Date:Thu, 2 May 2024 11:10:36 -0400
From:Chet Ramey
Message-ID:
| There's no real difference between the two statements; there is a
| clarification for consistency with the language in the new "Job
| Control" section in Issue 8.
None of that really matters -
Date:Tue, 30 Apr 2024 10:29:43 -0400
From:Chet Ramey
Message-ID: <958687ce-7e36-42d1-a82e-6101fc777...@case.edu>
| That's an interpretation. I might buy it if the DESCRIPTION didn't say
|
| "When jobs reports the termination status of a job, the shell shall
Date:Mon, 29 Apr 2024 16:07:26 -0400
From:Chet Ramey
Message-ID: <11d627e9-174c-40a8-b827-0a2678d58...@case.edu>
| So the question is what exactly constitutes a foreground job whose status
| has "not been reported."
I doubt it is stated anywhere, but I would
Date:Thu, 18 Apr 2024 03:03:32 -0400 (EDT)
From:anonymous
Message-ID: <20240418-070332.sv0.619...@savannah.gnu.org>
| Arguments are given after the program name and are used to modify the
| program's operation. E.g.: usage:
|
| somecommand --help
But when I
Date:Sat, 13 Apr 2024 16:10:26 -0400
From:Chet Ramey
Message-ID: <32bd9e76-24bc-4206-aa8a-8bcc81722...@case.edu>
| File descriptors the user saves with exec redirections beyond [0-2]
| are set to close-on-exec. POSIX makes that behavior unspecified, but
| bash
Date:Thu, 11 Apr 2024 15:54:21 +0100
From:"Kerin Millar"
Message-ID: <57e307d0-6a16-443b-82ce-adf540f96...@app.fastmail.com>
| The behaviour of dash seems more logical to me,
| though I am uncertain as to which shell is in the right.
In as much as how aliases
Date:Thu, 11 Apr 2024 11:05:43 +0200
From:Philipp Lengauer
Message-ID:
| When defining aliases and then exporting a function uses these aliases, the
| exported function body has the aliases expanded. This makes sense because
| we cannot be sure the same
Date:Mon, 8 Apr 2024 19:35:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Why not? It works fine with other shells
Sure, it is possible to make a useless program like this ...
| $ cat tst.sh
| cat
Date:Mon, 8 Apr 2024 12:32:13 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| The only ash clone that does this is gwsh, all others print "a" and a
| command-not-found error.
I have (today, after your e-mail) changed the NetBSD shell so it works
like is
Date:Mon, 8 Apr 2024 00:29:41 -0400
From:John Passaro
Message-ID:
| if you wanted this for your script - read all then start semantics, as
| opposed to read-as-you-execute - would it work to rewrite yourself inside a
| function?
|
| function main() { ...
Date:Mon, 8 Apr 2024 02:50:29 +0100
From:Kerin Millar
Message-ID: <20240408025029.e7585f2f52fe510d2a686...@plushkava.net>
| which is to read scripts in their entirety before trying to execute
| the resulting program. To go about it that way is not typical of sh
In addition to what Chet said, I'd also point out that the forthcoming
POSIX version has altered this text in the current standard:
string A string to be written to standard output. If the first operand is -n,
or if any of the operands contain a character, the results
are
Date:Thu, 14 Mar 2024 09:53:37 -0400
From:Greg Wooledge
Message-ID:
| I don't quite understand what this is saying.
It was a weird attempt to explain the behaviour bel9w
| Do the variables have different names, or the same name?
Depends which vars you mean
Date:Tue, 12 Mar 2024 18:32:19 +1000
From:Martin D Kealey
Message-ID:
| You don't need '-n' when you specify a PID; the fix is simply to remove it.
That's OK, when there is exactly one PID, but for a task like this,
wait -n -p pid PID1 PID2 PID3 ...
| I think you forgot to look at the actual code in the Makefile here.
No, I didn't forget, I never intended to look, unpacking attached
tar.gz files is more effort than I'm willing to undertake.
| Every '$' is written as a '$$', exactly as you say it should.
OK, I guessed incorrectly ...
This whole discussuon has been a total mess.
First the original message didn't give nearly enough info.
That might have been in the attachment, but no-one should be
expecting people to do any needless work when you're asking
for (free) assistance - if you want help you need to make
it as easy as
Date:Tue, 27 Feb 2024 00:50:46 +0100
From:Emanuele Torre
Message-ID:
| To use esac as a pattern you need to use the (esac) syntax,
Or quote it
'esac')
(or similar).
kre
Date:Fri, 23 Feb 2024 10:45:01 -0500
From:Chet Ramey
Message-ID: <3544bf1c-e8f6-4358-a281-24bd1be7d...@case.edu>
| Do you mean that unset can mark local variables at the same
| scope as unset,
no, but see below.
| that unset can remove local variables at a
Date:Fri, 23 Feb 2024 09:15:09 +1000
From:Martin D Kealey
Message-ID:
| Yes, that's exactly the point, to *avoid* dynamic scoping. I want the
| equivalent of Perl's "my", rather than Perl's "local".
Lexical scoping does not, that is, cannot, work with the
Date:Mon, 19 Feb 2024 18:33:31 +0900
From:Koichi Murase
Message-ID:
| GNU grep started to output error messages in v3.8 (2022-09) for egrep,
| so the test failure will be happening in most GNU/Linux distributions
| soon.
That (as in, gnu grep) should be
Date:Sat, 17 Feb 2024 01:41:11 +0100
From:Damien ISSANCHOU
Message-ID:
| Even though the online Bash Reference manual only explicitly states
| the POSIX behaviour when the expansion of the special parameter * occurs
| within double-quotes, it seems that it
Date:Wed, 31 Jan 2024 11:35:57 -0500
From:Chet Ramey
Message-ID: <1e50aa99-8d53-4cdf-ba5e-6aaf3ccc6...@case.edu>
| Not quite. `new' in this sense is the opposite of `anything in the past'
| as Dale described it -- already notified and removed from the jobs list.
Date:Tue, 30 Jan 2024 10:14:10 -0500
From:Steven Pelley
Message-ID:
| If wait -n
| looked at terminated processes you'd return jobs repeatedly and
| possibly end up in an infinite loop.
That's another bash bug, POSIX says:
Once a process ID that is
Date:Tue, 30 Jan 2024 09:16:47 -0500
From:Chet Ramey
Message-ID: <95841ed3-ec4f-4b17-802c-86e560b58...@case.edu>
| since this was the way -n worked orginally, before it started
| paying attention to pid arguments.
I'm not sure what the "this" is there, if you
Date:Mon, 29 Jan 2024 12:07:53 -0500
From:Chet Ramey
Message-ID:
| What does `wait -n' without job arguments mean?
Find, or if there are none already, wait*(2) for, a process (job technically)
that has changed state (terminated in POSIX, and one day in the NetBSD
Date:Mon, 29 Jan 2024 13:54:10 +0100
From:Andreas Schwab
Message-ID:
| n = next?
That would be a reasonable interpretation, I guess, but
unfortunately not one which helps the current question,
as it doesn't answer "next what?" It could be "the next
of these
Date:Sun, 28 Jan 2024 18:21:42 -0500
From:Chet Ramey
Message-ID: <3347f790-529b-4bee-91fd-de39bed3f...@case.edu>
| because `wait -n' doesn't look in the table
| of saved statuses -- its job is to wait for `new' jobs to terminate, not
| ones that have already
Date:Fri, 12 Jan 2024 07:15:35 -0500
From:Greg Wooledge
Message-ID:
| This was one of the things I tested:
Perhaps intended to, but didn't, or not in this example:
| { read -N1; read -r b c; } < <(printf \\nabc); declare -p REPLY a b c
Rewrite that, correctly
Date:Thu, 11 Jan 2024 20:02:04 -0500
From:Greg Wooledge
Message-ID:
| What actually counts is how many
| characters are *stored* in the variable, not how many characters are
| *read* from the input.
I suspect that is the root of the issue here, you're
Date:Sun, 10 Dec 2023 18:59:22 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| There doesn't have to be a standard way; I'd set it in ~/.profile, you'd
| set it wherever is convenient on your setup.
The point is that the people who want this don't want to have
Date:Tue, 28 Nov 2023 19:27:17 -0500
From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?=
Message-ID:
| the first argument after the command string (in my case "a", and
| in your case "-bash") is used as $0 while executing that command
| string, and the remaining
Date:Sat, 25 Nov 2023 08:53:48 +0100
From:Emanuele Torre
Message-ID:
| But the bash executable still does not contain the legal_ symbols:
You'd only be getting symbols (.o files defining the symbols) loaded
from an archive format library (.a file) if something
Date:Sat, 18 Nov 2023 21:55:23 -0500
From:Jason Franklin
Message-ID:
| $ history -c; fc -0
| Segmentation fault (core dumped)
|
| Can someone else confirm this?
Which bash version are you using?
I just tried that on
GNU bash, version
Date:Sun, 19 Nov 2023 07:40:00 +1000
From:Martin D Kealey
Message-ID:
| The fact that you don't *want* the output of xclip connected to tr
| (because it makes tr wait for xclip *and all its children* to finish,
| while the shell waits for tr to finish) does
Date:Thu, 9 Nov 2023 16:55:50 -0500
From:Greg Wooledge
Message-ID:
| I believe *nothing* would work in that case;
There's no requirement (in fact, it is probably not a good idea) for
newlines in the output to be printed literally - whether entered literally
or
Date:Thu, 09 Nov 2023 21:04:28 +0100
From:Steffen Nurpmeso
Message-ID: <20231109200428.8g9lz%stef...@sdaoden.eu>
| ash(1) and busybox ash(1) do not even support jobs -l in a function (yet).
That seems unlikely, ash based shells mostly don't care whether the
Date:Thu, 9 Nov 2023 14:21:35 +0100
From:Mike Jonkmans
Message-ID: <20231109132135.ga208...@jonkmans.nl>
| If I am not mistaken, for POSIX compliance, both /bin and /usr/bin have
| to be in PATH (see quote from Robert).
No, I didn't say that, there are no
Date:Tue, 7 Nov 2023 23:04:10 +0100
From:Mike Jonkmans
Message-ID: <20231107220410.gc27...@jonkmans.nl>
| In particular, a user function with the name of a standard utility,
| will be called at this point.
Yes. That much is very clear.
| Chet mentioned
Date:Mon, 6 Nov 2023 14:28:24 -0500
From:Chet Ramey
Message-ID: <0ab6075e-22bf-43cd-992c-b2476f626...@case.edu>
| On 11/6/23 10:48 AM, Mike Jonkmans wrote:
| > According to these docs (what I make of it), resolving is done
| > in steps, the first applicable
Date:Sat, 28 Oct 2023 22:49:13 -0700
From:Paul Eggert
Message-ID:
| I don't know what bosh is.
bosh is a modernised (updated) variant of the SysVR4 Bourne shell
I believe - it used to be maintained by Joerg Schilling (and still
contains bugs).
| PS. As I
Date:Sat, 14 Oct 2023 14:46:12 +1000
From:Martin D Kealey
Message-ID:
| Back when I used the Bourne Shell we didn't have `local`, so we used to
| write `var= func` to make sure that `func` couldn't mess with *our* `var`.
If you were using the original Bourne
Date:Fri, 13 Oct 2023 14:21:59 -0400
From:"Dale R. Worley"
Message-ID: <87bkd2idrs@hobgoblin.ariadne.com>
| but I coded an instance of
| your description (above), and it does not show the dubious behavior that
| you report.
Your test isn't accomplishing
Date:Thu, 12 Oct 2023 21:36:48 -0700
From:Grisha Levit
Message-ID:
| There are some issues with parser output when the input has an unquoted
| backslash followed by a raw ^A character:
The NetBSD shell (and probably other ash derived shells) used to
have
Date:Thu, 12 Oct 2023 16:11:09 -0700
From:Grisha Levit
Message-ID:
| If we want to preserve the behavior of unquoted backslash
| causing a following
| quoted character to become unquoted after quote_string_for_globbing:
Please don't. Something explicity
Date:Mon, 9 Oct 2023 14:51:29 -0400
From:Chet Ramey
Message-ID:
| That's my beef, but, strictly speaking, neither do pushd/popd/dirs.
Those we have as (optional) functions only, but no-one uses
them (with the NetBSD sh) that I know of.
But they're not really in
Date:Mon, 9 Oct 2023 10:35:20 -0400
From:Chet Ramey
Message-ID:
| There is surprising variance in behavior here, from a status of 2 to 1
| to 0 (dash), plus the silly ksh "substitute old for new in $PWD," which
| the NetBSD sh (!) also performs.
Yes, we do...
Date:Tue, 19 Sep 2023 18:09:13 +0100
From:Kerin Millar
Message-ID: <20230919180913.bd90c16b908ab7966888f...@plushkava.net>
| > | On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote:
| > | > in let "<>" and $((<>)) constructs all variables should be
| > |
Date:Tue, 19 Sep 2023 09:52:21 +0100
From:"Kerin Millar"
Message-ID: <4c2e3d39-0392-41ae-b73c-3e17296a9...@app.fastmail.com>
| On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote:
| > Thanks for your response.
| > In my opinion, in let "<>" and $((<>))
Date:Thu, 7 Sep 2023 13:46:08 -0500
From:Eric Blake
Message-ID:
| Right now, both bash and coreutils' 'printf %hhd 257' outputs "257",
ok, not unexpected. I'm not sure its useful either.
| but printf("%hhd", 257) in C outputs 1.
Yes.
| I would LOVE to
And for those who have been following this issue, the new text for
the forthcoming POSIX version has removed any mention of obsoleting
%b from printf(1) - instead it will simply note that there is will be
a difference between printf(1) and printf(3) once the latter gets its
version of %b specified
Date:Wed, 6 Sep 2023 11:03:25 -0500
From:Eric Blake
Message-ID:
| If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
| between printf(1) and printf(3).
Yes.
| If we reach out to all developers now, we can start the discussion,
That would
Date:Wed, 6 Sep 2023 11:32:32 -0500
From:Eric Blake
Message-ID:
| You (anyone reading this, not just kre) are welcome to join tomorrow's
| Austin Group meeting
Thanks, but I don't expect its time of day will coincide with
mine this week, at best I would be a
Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic
Message-ID: <03abecb9d905252bd63867d1c8b2a...@manjaro.org>
| It's good to know that the
| 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
As Chet said, that is not what I meant. The
Date:Wed, 6 Sep 2023 08:13:23 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| What's the point? Does anyone need this feature in their shell scripts (and
| can't afford to use bc for it)?
Adding a different %b to printf(1) wasn't currently even proposed, just
Date:Tue, 05 Sep 2023 22:32:39 +0200
From:Dragan Simic
Message-ID: <7cfed11b50d35cbfaaa647c1fcd39...@manjaro.org>
| Are there any official explanations why is the invalidation actually
| happening now?
It was proposed because of a desire to keep the formats for
Date:Sun, 2 Jul 2023 21:04:38 -0400
From:Greg Wooledge
Message-ID:
| The first assignment is done before the value of "m" is used in the second
| assignment.
Note that that is a shell specific feature, applies to bash, but
not necessarily to other shells (some
Date:Fri, 30 Jun 2023 20:21:20 -0400
From:Eli Schwartz
Message-ID:
I suggested using set partly because it should work in any shell.
The need, or even ability, to set posix mode is likely to differ,
but that is minor. In general I vastly prefer highly portable
Date:Fri, 30 Jun 2023 18:35:34 +0100
From:Kerin Millar
Message-ID: <20230630183534.85da7986a24855126bfea...@plushkava.net>
| This can be trivially foiled.
You mean it doesn't give you all the variable names? Why not?
Does bash have a bug in this area that I am
Date:Thu, 29 Jun 2023 23:05:38 +0100
From:Kerin Millar
Message-ID: <20230629230538.cbef14a75694143ccf034...@plushkava.net>
| The thing is that portage also has a legitimate stake in needing
| to enumerate all variable names.
Why isn't "set" good enough for that?
Date:Tue, 27 Jun 2023 07:44:56 -0400
From:Greg Wooledge
Message-ID:
| I'm seeing some parser voodoo here.
Not doing field splitting, or globbing, is normal for any assignment statement.
Consider the simple (no arrays involved)
IFS=$', \t\n'
var=x*,y?
final=$var
Date:Tue, 27 Jun 2023 07:29:42 +0200
From:n952162
Message-ID:
I suspect this message really should have gone to the bash-help list.
Never mind:
| If so, why?
I think this is related to the message I sent to the list early
this morning (my time) -- bash is
Date:Mon, 26 Jun 2023 10:32:19 +0100
From:Kerin Millar
Message-ID: <20230626103219.0f74c089c616248cee6ab...@plushkava.net>
| Further, declare is granted special treatment, even after having been
| defined as a function (which might be a bug).
That will be
Date:Fri, 02 Jun 2023 01:01:08 +
From:rpaufin1
Message-ID:
| What's going on here? I'm using the latest release, Bash 5.2.15.
Bash is doing what it it is supposed to be doing. Just don't use -e
unless you are an expert in what it actually means, and once
Date:Wed, 31 May 2023 10:07:07 -0400
From:Chet Ramey
Message-ID:
| The documentation can always be changed to match a change in behavior.
Of course, but you only do that wen the doc is either unclear, or
when the behaviour change is obviously to something better.
Date:Tue, 30 May 2023 15:28:57 -0400
From:Chet Ramey
Message-ID:
| H. That's not the only option. How about we load it if found but mark
| it as not enabled? It will still take `enable -d' to delete it.
That wouldn't match the man page, and isn't really
Date:Sun, 28 May 2023 16:05:04 +1000
From:Martin D Kealey
Message-ID:
| PS: Everyone assumes that "the speed of external executables is the
| limiting factor", but it turns out that's not true. It's possible to do
| MUCH worse, just using built-in features:
Date:Thu, 25 May 2023 10:17:01 -0400
From:Chet Ramey
Message-ID:
| a nofork command substitution is
| '${' compound_list '}',
you omitted the extra char there, not that it matters for
the purpose here.
| The difference, as you say, is
| that a command
Date:Thu, 25 May 2023 19:29:40 +0900
From:Koichi Murase
Message-ID:
| Does that mean ${(command)} would be explicitly unsupported even
| though {(command)} is allowed for the brace grouping?
The two are mostly unrelated.
| Would other cases without
Date:Mon, 22 May 2023 02:43:18 -0300
From:Aleksey Covacevice
Message-ID:
| I fail to see where the race condition in `true & wait -n` is.
It wasn't in the script - but in the implementation inside bash.
Chet has (apparently, I don't look at bash sources, and
Date:Fri, 19 May 2023 12:03:51 -0400
From:Chet Ramey
Message-ID: <0a85095a-1665-d936-b4fa-118dd158e...@case.edu>
| Maybe, and certainly possible, but a more likely use is just a simple
| assignment to REPLY.
In such cases, the value to be assigned needs to come
Date:Thu, 18 May 2023 14:07:32 -0400
From:Chet Ramey
Message-ID:
| This isn't a problem, and is a red herring. The code that manages that list
| makes sure to keep as many jobs in the list as POSIX requires, subject to
| the maxchild resource limit.
That is
Date:Thu, 18 May 2023 22:14:28 -0400
From:"Dale R. Worley"
Message-ID: <874jo9kqyj@hobgoblin.ariadne.com>
| Chet Ramey writes:
| > Bash allows the close brace to be joined to the remaining
| > characters in the word without being followed by a shell
Date:Thu, 18 May 2023 07:35:35 -0400
From:Greg Wooledge
Message-ID:
| I'm fairly sure most (or all?) shells do this, not just bash.
Interactive shells are "different" from those running a script in
this regard.
kre
Date:Thu, 18 May 2023 14:16:17 +1000
From:Martin D Kealey
Message-ID:
| I know that some platforms (used to?) lack all of the âwaitpid()â,
This is irrelevant to the issue at hand (and in general, for shells, is
irrelevant anyway, as shells usually always
Date:Wed, 17 May 2023 17:23:21 +1000
From:Martin D Kealey
Message-ID:
| I suspect putting "local" in a loop is doing something strange.
"local" is an executable statement, not a declaration (shell really
has none of the latter) - every time it is executed it
Date:Mon, 8 May 2023 11:13:19 -0400
From:Chet Ramey
Message-ID: <4c66cc58-27f7-4001-c831-8a2a23264...@case.edu>
| I see I might need to update the error message to specify it's process
| substitution.
You might want to (for this particular case anyway) want to
Date:Sun, 2 Apr 2023 17:48:24 +0200
From:Martin Schulte
Message-ID: <20230402174824.01db4d51fd4f0061fdba7...@schrader-schulte.de>
| in the following lines I consider dash's behaviour as correct
| an bash's as wrong:
All other shells (even ksh93) not just dash.
Date:Sat, 1 Apr 2023 18:49:56 -0600
From:Felipe Contreras
Message-ID:
| Fortunately kre did listen.
Not really.I agree that what POSIX currently says is not correct,
which is why the defect report got filed (you may have noticed that there
was no new wording
Date:Sat, 1 Apr 2023 19:44:10 -0400
From:Saint Michael
Message-ID:
| The compelling reason is: I may not know how many values are stored in the
| comma-separated list.
Others have told you you're wrong, but this is not any kind of compelling
reason - you
Date:Fri, 31 Mar 2023 14:41:37 -0400
From:Chet Ramey
Message-ID: <625e93f4-280b-2cd4-f84d-2305bd347...@case.edu>
| On 3/31/23 12:30 PM, Martin Schulte wrote:
| > Hi Chet!
| >
| >> Thanks for the report. The synopsis should read
| >>
| >> cd [-L|[-P
While it is probably useful to have every place where expansions occur list
which ones apply, perhaps it would (also) be useful to include the general
principle which controls all of this.
That is, expansions are performed, late (just as commands are about to
be run, after all parsing has
Date:Thu, 09 Mar 2023 09:26:18 +0100
From:Andreas Schwab
Message-ID:
| But an unset PATH is *not* the same as PATH=.
That might be true, but POSIX says:
If PATH is unset or is set to null, or if a path prefix in PATH
contains a character ('%'),
Date:Sat, 18 Feb 2023 12:21:49 +1000
From:Martin D Kealey
Message-ID:
| Both of these are clearly wrong,
Yes, which is why POSIX is changing. I am concerned less about
bash (and other shell) doc about the details of all of this,
more useful to suggest that
Date:Wed, 15 Feb 2023 11:57:45 -0500
From:Chet Ramey
Message-ID: <8295e33a-da67-676c-66cb-9593871ce...@case.edu>
| However, it might be time to change this again, since the ultimate
| resolution of issue 654 resulted in POSIX removing the special handling of
|
Date:Tue, 14 Feb 2023 11:04:48 -0500
From:Chet Ramey
Message-ID: <8be447ca-5416-a64f-7e62-1e61102e8...@case.edu>
| "Special builtin" is not a particularly useful concept
I disagree - most of the time the difference doesn't matter much,
but that the special
Date:Sun, 12 Feb 2023 01:14:12 +0900
From:Koichi Murase
Message-ID:
| `jobs' can be overwritten by a shell function. For example, when a
| user wants to modify the behavior of `jobs' for interactive uses, a
| typical solution is to override `jobs' with a
1 - 100 of 443 matches
Mail list logo
