Hi,
It seems some things are missing in the bash manual.
Notably definition of command and placements of coproc- and function-definition.
The section 'SHELL GRAMMAR' describes:
- simple-command
- pipeline
- list
- compound-command
- coproc
- function-definition
Simplified, a pipeline is:
On Tue, Feb 23, 2021 at 04:33:44PM -0500, Chet Ramey wrote:
> On 2/22/21 8:11 AM, Mike Jonkmans wrote:
> >
> > Hi,
> >
> > It seems some things are missing in the bash manual.
> > Notably definition of command and placements of coproc- and
> > function-
On Wed, Feb 24, 2021 at 12:08:50PM -0500, Chet Ramey wrote:
> On 2/23/21 7:31 PM, Mike Jonkmans wrote:
> > On Tue, Feb 23, 2021 at 04:33:44PM -0500, Chet Ramey wrote:
> > > On 2/22/21 8:11 AM, Mike Jonkmans wrote:
> > > >
> > > > Hi,
> > > >
On Thu, Feb 25, 2021 at 11:15:36PM +0100, Ángel wrote:
> On 2021-02-25 at 16:13 +0100, Mike Jonkmans wrote:
> >
> > Aren't grammars taught already in primary school? It is in the
> > Netherlands.
> > But i agree that it is a good thing to let the text not depend
On Thu, Feb 25, 2021 at 06:28:34PM -0500, Chet Ramey wrote:
> On 2/25/21 10:13 AM, Mike Jonkmans wrote:
> > Starting with 'Statements' might be an option.
>
> Maybe. Or a POSIX-like description that says a command can be a
>
> simple command
> list
> p
On Fri, Feb 26, 2021 at 02:54:07AM +0100, Ángel wrote:
> On 2021-02-26 at 00:45 +0100, Mike Jonkmans wrote:
> > On Thu, Feb 25, 2021 at 11:15:36PM +0100, Ángel wrote:
> >
> > Those grammars weren't all that different from yacc's grammar.
> > Just simpler and
On Fri, Feb 26, 2021 at 12:41:44PM -0500, Chet Ramey wrote:
> On 2/26/21 11:22 AM, Mike Jonkmans wrote:
>
> > I don't think that f.i. precedence was taught.
> > Although you get that with arithmetic, which also has a grammar.
>
> It's not taught as such. Kids to
grammar doesn't mention the word 'function'.
Posix does mention it, as reserved word recognized by 'some implementations'
and causing undefined behavior.
Regards, Mike Jonkmans
On Sun, Feb 28, 2021 at 05:06:37PM -0500, Chet Ramey wrote:
> On 2/28/21 12:38 PM, Mike Jonkmans wrote:
>
> > The manual page says:
> > If the function reserved word is used, but the parentheses are not
> > supplied,
> > the braces are required.
>
>
The -x option to ctags generates 'human readable' stuff that vim can not use.
This patch removes the -x and the '>$@', which is not needed.
Refer to https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ctags.html
Also introducing $(ETAGS) $(ETAGSFLAGS) and same fo
I assume that the TAGS and tags files will not go into the repo.
Regards, Mike Jonkmans
diff --git .gitignore .gitignore
index 1512a9ab..f09f4eac 100644
--- .gitignore
+++ .gitignore
@@ -113,3 +113,6 @@ examples/loadables/tty
examples/loadables/uname
examples/loadables/unlink
examples
On Mon, Mar 15, 2021 at 11:23:46AM -0400, Chet Ramey wrote:
> On 3/15/21 3:29 AM, Mike Jonkmans wrote:
> > I assume that the TAGS and tags files will not go into the repo.
>
> Why not? This is only the devel branch; they don't go into releases.
Adding tags/TAGS to the rep
On Mon, Mar 15, 2021 at 04:06:06PM -0500, Eric Blake wrote:
> But even if the upstream repo doesn't want to ignore a file in the
> (checked-in) .gitignore, you can always edit your (local-only)
> .git/info/exclude to exclude your extra files locally.
Thanks Eric, that is useful.
A 'make distclean' removes lib/readline/doc/Makefile
It is a handmade Makefile, so probably should not be removed.
Idem for maintainer-clean.
Regards, Mike Jonkmans
diff --git lib/readline/doc/Makefile lib/readline/doc/Makefile
index af5ee3e5..6bc2e5ea 100644
--- lib/readline/do
ho $BASH_VERSION
5.0.17(1)-release
$ alias n=bla
$ n() { type $FUNCNAME; }
$ declare -pf n
bash: declare: n: not found
$ declare -pf bla
bla ()
{
type $FUNCNAME
}
It is the same on 5.1.4(1)-release.
I would have expected that n was a defined function.
But I would not have bet on it.
Regards, Mike Jonkmans
k that the line
aval = expand_assignment_string_to_string (v, 0);
should be moved down below the next if-statement.
Because of the continue, there is a memory leak.
Regards, Mike Jonkmans
h/2017-04/msg00063.html
> https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00052.html
There is also uselocale, newlocale, duplocale and freelocale.
The manual says POSIX.1-2008, so it should be reasonably portable.
Not sure if it is worth the trouble.
Regards, Mike Jonkmans
On Mon, Jul 26, 2021 at 03:57:16PM +0200, Alex fxmbsw7 Ratchev wrote:
> ..
..: command not found
Regards, Mike Jonkmans
ouble quotes
instead of single quotes. This might expose the script to the
translated
result. For compatibility reasons, this option is enabled by default.
Regards, Mike Jonkmans
ms to be the fastest:
f12 () { [[ "$1" =~ ${1//?/(.)} ]]; local arr=( "${BASH_REMATCH[@]:1}" ); }
time for ((i=1; i<=1; i++)); do f0 682390; done
real0m0,296s
user0m0,296s
sys 0m0,000s
Regards, Mike Jonkmans
On Tue, Aug 24, 2021 at 09:24:35AM -0400, Greg Wooledge wrote:
> On Tue, Aug 24, 2021 at 03:09:55PM +0200, Mike Jonkmans wrote:
> > This seems to be the fastest:
> > f12 () { [[ "$1" =~ ${1//?/(.)} ]]; local arr=( "${BASH_REMATCH[@]:1}" ); }
> > time for (
On Tue, Aug 24, 2021 at 04:16:46PM +0200, Léa Gris wrote:
> Le 24/08/2021 à 15:09, Mike Jonkmans écrivait :
> > This seems to be the fastest:
> > f12 () { [[ "$1" =~ ${1//?/(.)} ]]; local arr=( "${BASH_REMATCH[@]:1}" ); }
>
> Awesome Mike, would you like t
gt; 9
>
> Please help explain
Not a bug.
If you leave out the |tail -1', you will see that
the output of head -1 gets appended to that of tee.
--
Regards, Mike Jonkmans
Run command with args suppressing the normal shell function lookup.
Only builtin commands or commands found in the PATH are executed.
...
I think the hash lookup should be mentioned,
as the hash lookup is done before the builtin/PATH search, e.g.:
PATH=/
On Sun, Oct 31, 2021 at 03:33:07PM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 2:15 PM Mike Jonkmans wrote:
> > PATH=/dev/null
> > command -p hostname
> > hostname # executes /bin/hostname via the hash table
> >
> > I agree with OP that th
On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> >
> > Using the hash as alias for commands, that are not in your PATH,
> > seems risky though.
>
> Why? Risky how?
Risky, mostly on a cognitive level.
'c
On Sun, Oct 31, 2021 at 08:36:49PM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 7:07 PM Mike Jonkmans wrote:
> >
> > On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> > > 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> > > >
> > > > Using
On Mon, Nov 01, 2021 at 09:09:19AM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans wrote:
> > POSIX is also silent on this.
>
> I think ``Once a utility has been searched for and found [...], an
> implementation may remember its location and need not search
On Mon, Nov 01, 2021 at 12:21:41PM +0300, Oğuz wrote:
> On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote:
> > This wording does not cover it wholly, in my opinion.
> > Because when the utility's hashed path is not in $PATH,
> > then the utility should not have been s
(temporary) modified PATH comes from.
Good point!
> ps: should this be discussed for clarification in POSIX, I have no doubt
> which way the result would go.
There is the issue of 'command -p ...' changing the hash table.
Another issue is, the usage of hashed values
that a
>
> A mild annoyance at best, don't you think?
Mostly an annoyance, but it has potential to be a security issue.
Regards, Mike Jonkmans
mmand
"\e[200~": bracketed-paste-begin
## The initial escape is eaten, when pasting in insert mode:
"[200~": bracketed-paste-begin
## Start with the last 'set keymap' mode
set keymap vi-insert
"\e[200~": bracketed-paste-begin
Hope that it helps.
--
Regards, Mike Jonkmans
g.tar?(.!(sig|.*)))shopt
> -u extglob}xEOFResults in:
>
> bash: line 3: syntax error near unexpected token `('
>
> bash: line 3: `mapfile -t packages < <(printf "%s\n"
> "dir"/"dir"/"dir"/"{targetname}"-"${targetver}"-"${targetarch}".pkg.tar?(.!(sig|.*)))'
>
> Putting shopt options outside the function, but is this the wanted
> behaviour?
> ...
> Tobias Powalowski
--
Regards, Mike Jonkmans
l
refers to a website pointing out problems with gettimeofday.
That website was (presumably) written in 2010/09 :
https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html
So it is not that new.
It is another special case in code, which may explain the slow uptake in tools,
many of which need to be portable.
--
Regards, Mike Jonkmans
On Fri, Mar 31, 2023 at 06:30:00PM +0200, Martin Schulte wrote:
> Hi Chet!
>
> > Thanks for the report. The synopsis should read
> >
> > cd [-L|[-P [-e]]] [-@] [dir]
> ^ ^
> But aren't these two brackets just superfluous?
Then -L would get the -e too.
--
Regards, Mike Jonkmans
p?id=1649
Thanks for the link.
And well done, kre!
--
Regards, Mike Jonkmans
ls; hash -td ls
And -d ignores -l:
hash ls; hash -ld ls
Conclusion
I would say that:
- Combining options should error;
- Except for an added -r, which first clears;
- 'hash -l x' shouldn't add, but print what 'hash -lt x' currently prints;
- 'hash -d x' a
On Mon, Sep 11, 2023 at 03:25:01PM -0400, Chet Ramey wrote:
> On 9/6/23 10:55 AM, Mike Jonkmans wrote:
> > The following 'hash -d' statements have different exit statuses.
> >
> > bash --noprofile --norc -c \
> > 'hash -d ls; echo $
On Wed, Sep 13, 2023 at 11:32:36AM -0400, Chet Ramey wrote:
> On 9/12/23 8:28 AM, Mike Jonkmans wrote:
> > On Mon, Sep 11, 2023 at 03:25:01PM -0400, Chet Ramey wrote:
> > > On 9/6/23 10:55 AM, Mike Jonkmans wrote:
...
> > > > 3) These option combinations should erro
12 years ago in devel
(10 years ago in master, bash 4.3).
Since then nobody disabled aliases or took the trouble of reporting.
Wouldn't it be opportune to remove the `--enable-alias' option?
Saves a couple of #ifdef's too.
--
Regards, Mike Jonkmans
pcomplete.c | 6 +++---
1
Hi,
The 'times' utility is not listed as a posix special builtin
in doc/bashref.texi
It can be fixed by changing:
@w{shift trap unset}
to:
@w{shift times trap unset}
--
Regards, Mike Jonkmans
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
--
Regards, Mike Jonkmans
Thanks for the answers, Chet.
On Mon, Nov 06, 2023 at 02:28:24PM -0500, Chet Ramey wrote:
> On 11/6/23 10:48 AM, Mike Jonkmans wrote:
>
> > Q: Why check for regular builtins? That was already done in 1d.
> Implementations can provide other builtins. The check in 1d is only for
&
On Tue, Nov 07, 2023 at 09:39:33AM +0700, Robert Elz wrote:
> 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:
> | > Acco
On Tue, Nov 07, 2023 at 11:49:25AM -0500, Chet Ramey wrote:
> On 11/7/23 8:54 AM, Mike Jonkmans wrote:
...
> > > Look at https://www.austingroupbugs.net/view.php?id=854 for a discussion
> > > of this issue.
> > Thanks for the link, I find that very hard to read tho
On Wed, Nov 08, 2023 at 10:38:19AM -0500, Chet Ramey wrote:
> On 11/7/23 5:04 PM, Mike Jonkmans wrote:
>
> It depends on your requirements. If you want something that is easy to
> explain to users, you want to reduce the distinction between `intrinsics'
> and `regular built
On Wed, Nov 08, 2023 at 11:52:19PM +0700, Robert Elz wrote:
> Date:Tue, 7 Nov 2023 23:04:10 +0100
> From: Mike Jonkmans
> Message-ID: <20231107220410.gc27...@jonkmans.nl>
>
> | It makes sense to partition the builtins in three categories with
On Wed, Nov 08, 2023 at 10:42:20AM -0500, Chet Ramey wrote:
> On 11/7/23 5:37 PM, Mike Jonkmans wrote:
> > On Tue, Nov 07, 2023 at 11:49:25AM -0500, Chet Ramey wrote:
> > > On 11/7/23 8:54 AM, Mike Jonkmans wrote:
> > So the discussion is hidden. Hmm.
> Not hidden; if y
On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote:
> 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/bi
On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote:
> On 11/9/23 11:17 AM, Mike Jonkmans wrote:
> > On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote:
> >
> > On Ubuntu 22.04 `getconf path' returns /bin:/usr/bin
> > and these are symlinked.
> T
On Sat, Nov 11, 2023 at 08:31:14AM -0500, Greg Wooledge wrote:
> On Sat, Nov 11, 2023 at 09:14:41AM +0100, Mike Jonkmans wrote:
> > On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote:
> > > On 11/9/23 11:17 AM, Mike Jonkmans wrote:
> > > > On Thu, Nov 09, 20
he first.
Returning to `shell-expand-line'.
As end user I would expect that, running shell-expand-line then accept-line,
would do the same as just an accept-line.
Quote removal is absolutely needed, otherwise expansions may mess up
the result when they introduce quotes.
I think that escaping is needed after quote removal in shell-expand-line.
--
Regards, Mike Jonkmans
On Thu, Feb 01, 2024 at 08:14:34PM -0500, Chet Ramey wrote:
> On 1/31/24 6:05 PM, Mike Jonkmans wrote:
>
> > The first sentence under EXPANSION may make you think otherwise:
> >Expansion is performed on the command line after it has been split into
> > words.
> &g
mode it might be nice if the cursor didn't move onto the
last character.
vi-insert mode: `ls *' cursur is after the `*'
then going to vi-command mode, the cursor moves onto the `*'.
This prevents the `glob-expand-word' from doing its thing.
--
Regards, Mike Jonkmans
On Fri, Feb 02, 2024 at 10:09:53AM -0500, Chet Ramey wrote:
> On 2/2/24 8:12 AM, Mike Jonkmans wrote:
> > On Thu, Feb 01, 2024 at 08:14:34PM -0500, Chet Ramey wrote:
> > "There are seven kinds of expansion..." then three sentences later comes
> > quote removal. The
On Fri, Feb 02, 2024 at 09:50:46AM -0500, Greg Wooledge wrote:
> On Fri, Feb 02, 2024 at 03:39:54PM +0100, Mike Jonkmans wrote:
> > [ mkdir test; cd test; touch file1 file2 ]
> >
> > Going into `vi-command' mode on the line `ls *' puts the cursor on the `*
On Sat, Feb 03, 2024 at 03:43:45PM -0500, Chet Ramey wrote:
> On 2/2/24 9:39 AM, Mike Jonkmans wrote:
> > From the manual, glob-expand-word:
>
> glob-expand-word doesn't work that great in vi command mode, mostly for
> the reasons you suspect. What made you use it ov
On Sat, Feb 03, 2024 at 04:59:08PM -0500, Chet Ramey wrote:
> On 2/2/24 5:15 PM, Mike Jonkmans wrote:
> > On Fri, Feb 02, 2024 at 09:50:46AM -0500, Greg Wooledge wrote:
> > > On Fri, Feb 02, 2024 at 03:39:54PM +0100, Mike Jonkmans wrote:
> > > > [ mkdir te
## C-xq (let's assume it quotes the redirections)
$ printf "<%s>\n" x y
The original words before quote removal should be requoted.
Also when expansion introduces quotes:
$ x=\"
$ printf "$x\n" ## M-C-e-new (shell-expand-quoted?)
$ printf "\"\n"
$ printf $x\\n ## M-C-e-new
$ printf \"\\n
Oh well, I am happy with the undo :)
--
Regards, Mike Jonkmans
to a
> `declare' command when applied to a local variable at the current scope,
> even if there are no attributes to be displayed. Agreed?
>
> I am less convinced about outputting a `-g' for a global variable when
> called from a function scope, but I could be persuaded.
This would be logical.
Forgot the use case, but it was about a year ago that I needed this.
--
Regards, Mike Jonkmans
On Tue, Mar 19, 2024 at 02:24:34PM -0400, Chet Ramey wrote:
> On 3/19/24 11:50 AM, Mike Jonkmans wrote:
>
> > > Yes. There is one thing missing: the transformation should expand to a
> > > `declare' command when applied to a local variable at the current scop
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
On Sun, May 27, 2018 at 01:05:59PM -0400, Chet Ramey wrote:
> Date: Sun, 27 May 2018 13:05:59 -0400
> From: Chet Ramey
> To: Mike Jonkmans , bug-bash@gnu.org,
> b...@packages.debian.org
> Cc: chet.ra...@case.edu
> Subject: Re: BASH_ALIASES assignment allow special characters
&
On Sat, Mar 10, 2018 at 04:50:22PM -0500, Chet Ramey wrote:
> On 3/10/18 9:46 AM, bash...@jonkmans.nl wrote:
>
> > Bash Version: 4.4
> > Patch Level: 12
> > Release Status: release
> >
> > Description:
> > When a function is ran in a subshell environment (via backticks),
> > the program r
sh truncates to 8 bit.
Posix probably doesn't specify the behaviour because there is no common ground
between shells.
I would suggest bash always has its $? values between 0..255 (or at least
non-negative)
> https://unix.stackexchange.com/questions/99112/default-exit-code-when-process-is-terminated/99134#99134
Missed that one. Thanks.
>
> --
> Stephane
--
Mike Jonkmans
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
On Fri, Jul 12, 2019 at 10:14:19AM -0400, Greg Wooledge wrote:
> Date: Fri, 12 Jul 2019 10:14:19 -0400
> From: Greg Wooledge
> To: Mike Jonkmans
> Cc: bug-bash@gnu.org, b...@packages.debian.org
> Subject: Re: background, pipeline, hang
>
> On Fri, Jul 12, 2019 at 04:00:57PM
On Fri, Jul 12, 2019 at 02:26:52PM -0400, Chet Ramey wrote:
> Date: Fri, 12 Jul 2019 14:26:52 -0400
> From: Chet Ramey
> To: Mike Jonkmans , bug-bash@gnu.org,
> b...@packages.debian.org
> Cc: chet.ra...@case.edu
> Subject: Re: background, pipeline, hang
> Reply-To: chet.ra.
On Mon, Jul 15, 2019 at 10:01:30AM -0400, Chet Ramey wrote:
> On 7/13/19 5:55 AM, Mike Jonkmans wrote:
> > This runs for two seconds:
> > bash --norc --noprofile -ic "trap 'tput hs' DEBUG; sleep 2 & :|:|:"
>
> I can't reproduce this using bas
s also generated.
My expectation would be that:
- Alt-. insert text
- Esc goes to vi-command mode
- . does vi-redo, which is, insert the same text as Alt-. did
Regards,
--
Mike Jonkmans
On Tue, Jun 09, 2020 at 11:46:22AM -0400, Chet Ramey wrote:
>
> In any event, I believe the changes in the next devel branch push should
> fix these.
Thanks Chet, that explanation made sense.
If i can find the time I will try to test the devel branch.
Regards,
--
Mike Jonkmans
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.
b) an untracked file appears: buildconf.h
The patch addresses a).
Not sure what to do about b).
--
Regards, Mike Jonkmans
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.,
> > >
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 w
On Thu, Nov 07, 2024 at 06:05:36PM -0500, Chet Ramey wrote:
> On 11/4/24 9:44 AM, Mike Jonkmans wrote:
>
> > > > According to info (make)Standard Targets, we should have:
> > > > mostlyclean < clean < distclean < maintainer-clean
> > &
On Thu, Oct 24, 2024 at 03:07:46PM -0400, Grisha Levit wrote:
> These are reported by make --warn-undefined-variables.
>
> Most were being set previously (sometimes 20 years ago) and got left
> behind in recepies after their definitions have been removed. Others
> only get set in some configuratio
On Mon, Nov 11, 2024 at 03:30:53PM -0500, Chet Ramey wrote:
> On 11/8/24 4:15 PM, Mike Jonkmans wrote:
> > > > 2) The use of recursive make, makes it harder to do dependencies right;
> > > It's the best way to build using optional components and subdirectories.
>
o solve
in a restricted cli-environment.
It was nice when starting to learn scripting.
Unfortunately it has gone off the radar.
This comes close: https://www.learnshell.org/
--
Regards, Mike Jonkmans
27;, the whole if has 0 as status, due to #1.
The last pipeline is the 'false' command. So $PIPESTATUS = 1.
Both other examples, e.g. 'if false; then :; fi | true',
are, for PIPESTATUS purposes, equivalent to: 'true | true'.
--
Regards, Mike Jonkmans
On Mon, Dec 09, 2024 at 09:20:54PM +0100, Andreas Schwab wrote:
> On Dez 09 2024, Mike Jonkmans wrote:
> > So, with 'if false; then :; fi', the whole if has 0 as status, due to #1.
> > The last pipeline is the 'false' command. So $PIPESTATUS = 1.
> Why is `if
On Tue, Dec 10, 2024 at 05:10:08PM -0500, Chet Ramey wrote:
> On 12/10/24 4:41 AM, Mike Jonkmans wrote:
>
> > Also compare:
> > $ if false; then echo foo; fi
> > $ echo "ret = $?, status = ${PIPESTATUS[*]}"
> > ret = 0, status = 1
>
On Mon, Dec 09, 2024 at 11:33:02PM +0100, Andreas Schwab wrote:
> On Dez 09 2024, Mike Jonkmans wrote:
>
> > But the PIPESTATUS refers to the 'false' pipeline:
> > $ if false; then :; fi; echo ${PIPESTATUS[*]}
> > 1
>
> $ if false; then :; fi | tr
On Tue, Dec 10, 2024 at 09:28:31AM +0100, Ulrich Müller wrote:
> >>>>> On Mon, 09 Dec 2024, Mike Jonkmans wrote:
>
> >> Why is `if false; then :; fi' not a pipeline? It is a command, and the
> >> components of a pipeline are commands.
>
> &g
On Wed, Dec 11, 2024 at 07:44:02PM -0500, Lawrence Velázquez wrote:
> On Wed, Dec 11, 2024, at 3:50 AM, Mike Jonkmans wrote:
> > Or worse: '! true | ! true' is a syntax error!?
> > Also errors in dash, but not in ksh.
> > Can a command - as part of a pipeline - no
On Thu, Dec 12, 2024 at 03:56:52AM -0500, Lawrence Velázquez wrote:
> On Thu, Dec 12, 2024, at 2:01 AM, Mike Jonkmans wrote:
> > Yes, the posix grammar doesn't allow it.
> > But it is not clear, from the bash documentation,
> > that a pipeline is not a command.
> Su
86 matches
Mail list logo
