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
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 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 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 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 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
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
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
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
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
hough 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
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.
>
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 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
*.toc *.tp *.vr *.cps *.pgs \
+ *.fns *.kys *.tps *.vrs *.bt *.bts
install:
@echo "This documentation should not be installed."
--
Regards, Mike
--
Regards, Mike Jonkmans
nfigure --with and --enable options.
Like --with-bash-malloc --with-curses, --with-installed-readline.
I am not sure if the research to do that is worth the trouble.
So the above 'fixed' version would be fine with me.
--
Regards, Mike
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
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
## 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
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
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 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 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
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 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
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 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
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 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 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 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: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 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 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
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
&
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
--
Regards, Mike Jonkmans
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
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
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
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 $
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
p?id=1649
Thanks for the link.
And well done, kre!
--
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
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
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
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
>
> A mild annoyance at best, don't you think?
Mostly an annoyance, but it has potential to be a security issue.
Regards, Mike Jonkmans
(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
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
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 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 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 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
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=/
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
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
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 (
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
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
On Mon, Jul 26, 2021 at 03:57:16PM +0200, Alex fxmbsw7 Ratchev wrote:
> ..
..: command not found
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
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix6.1.9.0
Compiler: gcc -maix64
Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security
uname output: AIX aixutil07 2 7 00C07A304B00
Machine Type: powerpc-ibm-aix6.1.9.0
Bash Version: 5.0
Patch Level: 18
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
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
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
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.
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
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
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
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.
>
>
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 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
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 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 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 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 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-
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 09 Feb 2021 16:40, Chet Ramey wrote:
> On 2/9/21 11:51 AM, Mike Frysinger wrote:
> > On 09 Feb 2021 11:12, Chet Ramey wrote:
> >> On 2/8/21 11:54 PM, Mike Frysinger wrote:
> >>> this set of changes between bash-4.3 & bash-4.4:
> >>> https:
On 09 Feb 2021 11:12, Chet Ramey wrote:
> On 2/8/21 11:54 PM, Mike Frysinger wrote:
> > this set of changes between bash-4.3 & bash-4.4:
> > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e
>
> I'm glad you're upg
est.sh
#!/bin/bash
foo() {
false
return 0
}
shopt -s extdebug
trap 'echo invalid trap; exit 1' ERR
foo
echo "pass"
$ bash-4.3 ./test.sh
pass
$ bash-4.4 ./test.sh
invalid trap
the manual text for extdebug didn't change between the versions, so it's
not clear if this is overall intended as a bug fix.
-mike
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
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 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
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 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
o or more pipes, hangs when a background job is
running.
Only when the background job finishes, the shell prompts again.
Without the background job, the shell prompts immediately.
Repeat-By:
: | : | : ## immediately finishes
sleep 10 &
: | : | : ## this hangs (^C, ^\, ^Z do not help) until the sleep
finishes
Regards, Mike
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
o
say. Or at least remember to run through the FAQ. :)
Anyways, thanks for your feedback!
niedz., 13 sty 2019 o 02:43 Chet Ramey napisał(a):
> On 1/12/19 7:52 PM, mike b wrote:
> > Upon changing directory, with "//" passed as an argument, the trailing
> '/'
> &g
Upon changing directory, with "//" passed as an argument, the trailing '/'
is still displayed when cwd is looked up by Bash:
bash-5.0# cd //
bash-5.0# pwd
//
bash-5.0# echo $PWD
//
bash-5.0# PS1=${PS1/\$/\w\\$}
bash-5.0//# # \w -> "//"
bash-5.0//# /bin/pwd # <- coreutils implementation
/
bash-5.0
I have the full picture now. Thank you all for your feedback!
That's a good point, I haven't thought about it like this. I always thought
that each read always starts at the beginning of the file given fd points
at. So the fact that it changes offset is a bit surprising:
# echo word >t
# exec {in}
napisał(a):
> On Mon, Dec 31, 2018 at 2:37
Configuration Information:
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' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I
> After sifting out the non-useful information. :-)
That information was useful information regardless of whether I was
aware of it. :) I'm sure I'm not the only person who read your message.
> You are always eloquent! :-)
You as well!
--
Mike Gerwitz
signature.asc
Description: PGP signature
could
have represented an actual bug.
--
Mike Gerwitz
signature.asc
Description: PGP signature
sharing a stack with the
interpreter, then it's hard to come up with a good predetermined value.
FUNCNEST doesn't seem to work with the issue of recursive traps, though
(understandably).
--
Mike Gerwitz
signature.asc
Description: PGP signature
)
Indeed they should, but inevitably, such bugs do happen, and mine was a
particularly common pitfall: I was trying to set the variable from
within a subprocess. But it wasn't in a subprocss when I originally
wrote it.
> The proper way for a program to terminate itself upon catching a
> si
On Sat, Oct 06, 2018 at 12:33:22 -0400, Chet Ramey wrote:
> On 10/5/18 9:33 PM, Mike Gerwitz wrote:
>> The following code will cause a segfault on bash-4.4.19(1) on
>> GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
>> bash-4.3.11(1) as well as a Trisqu
1 - 100 of 524 matches
Mail list logo
