Date:Wed, 20 Feb 2019 10:08:44 -0500
From:Chet Ramey
Message-ID:
| Maybe. The standard doesn't actually say that anywhere as such.
Not in the words I used, but XCU 2.3 does say:
When it is not processing an io_here, the shell shall break
its inpu
Consider the script at the end of this email. It's effectively
impossible to get or to accept the various values.
Either that or I am doing something incredibly stupid.
(It took me a while to factor this down and try virtually every
workaround that would not involve writing exte
On 2/22/19 4:17 PM, Eduardo Bustamante wrote:
On Fri, Feb 22, 2019 at 3:24 AM Robert White wrote:
(...)
tail --lines=+3 /proc/partitions | grep -v ram |
while read -a RECORD
do
(...)
eval [${INLINE[UUID]}]=boo
(...)
done
echo " Keys: " "${![@]}" = &qu
Date:Sun, 24 Feb 2019 18:37:33 -0500
From:Grisha Levit
Message-ID:
| There are some what seem to be regressions (?) in bash-4.4 and
| bash-5.0 regarding the handling of "$@" expansion when it consists
| entirely of null strings.
I think these are actually mor
Date:Mon, 25 Feb 2019 17:38:07 -0500
From:Grisha Levit
Message-ID:
First, apologies from me for missing this message from you. I don't
know if my spam filters caught it (for some unknown reason) or whether
it was delivered and I simply discarded it without notici
Date:Fri, 1 Mar 2019 11:00:41 -0500
From:Chet Ramey
Message-ID: <91e964e9-a7e3-4f4e-ae9f-9ff3e3627...@case.edu>
| It's wasteful and not particularly useful to have
| the function definition text stored internally when you can regenerate an
| equivalent form from
Date:Fri, 8 Mar 2019 18:09:50 -0500
From:Grisha Levit
Message-ID:
| A few more that produce \177 in the output, though I'm not sure if
| these have defined output:
The ones using "$*" should be OK (well specified).
| And also variations like the below all ha
Date:Fri, 8 Mar 2019 19:18:29 -0500
From:Grisha Levit
Message-ID:
| bash removes the surrounding space in these cases (all other shells
| print `< X >'):
Must be something to do with null value for IFS. If IFS=Q (or anything
else not containing space or X) it
Date:Mon, 11 Mar 2019 15:55:55 -0500 (CDT)
From:Todd Lehman
Message-ID:
| The period (".") after "name" should not be there.
Yet, the rules of grammar say it must be, as that is the end of the
sentence. This is the perennial issue with mixing code samples into
E
Date:Mon, 11 Mar 2019 22:08:47 -0500 (CDT)
From:Todd Lehman
Message-ID:
| Ah. Maybe my initial e-mail wasn't clear.
No, it was fine, I understood the context OK - it is just that this
is one of those rock and hard place situations - the places where
there is no p
Date:Mon, 11 Mar 2019 23:15:14 -0500
From:Todd Lehman
Message-ID:
| In any case, please fix as you see fit.
First, to make one thing clear, I have nothing whatever to do
with maintaining bash (for reasons unrelated to anything here,
I won't even go close to its so
Date:Tue, 19 Mar 2019 08:25:50 -0400
From:Greg Wooledge
Message-ID: <20190319122550.khv5jp66iobjo...@eeg.ccf.org>
| Yes, just like here documents do. And have always done, in all shells.
That's not correct. There are shells that don't use files for here
docs.
Date:Sat, 23 Mar 2019 11:48:33 -0400
From:Chet Ramey
Message-ID: <36545673-c287-6d8a-5e99-004ce9c6b...@case.edu>
| Yes. It waits for the next process to exit and then reaps all exited
| children.
That doesn't sound very useful. Our version (the NetBSD sh) finds
I should have added in my previous reply, that using an
interactive shell to test this is useless, as even if
wait -n only returned one process, before the next command
prompt any other processes that have exited will be waited
upon and cleaned up anyway (and in that case, jobs type
output is appro
Date:Mon, 25 Mar 2019 10:49:32 -0400
From:Chet Ramey
Message-ID: <9c536452-4f4e-b309-7a99-e85235364...@case.edu>
Great to see that revised description of how it works, that makes
much more sense. I also should have tested it.
| `wait -n' is only useful in scripts
Date:Tue, 26 Mar 2019 10:55:53 +0100
From:Andreas Schwab
Message-ID:
| Even better, IMHO: "wait waits for the next job to terminate"
Something should allow for there being no waiting involved at all
if some job has already terminated but has not been waited for.
Date:Thu, 28 Mar 2019 17:27:24 -0400
From:Greg Wooledge
Message-ID: <20190328212724.aczkwjoyceeg6...@eeg.ccf.org>
| You have two problems here. Well, four really.
2 really, I think...
| First, your first example invokes platform-defined behavior.
Technically,
Date:Fri, 29 Mar 2019 08:41:49 -0400
From:Greg Wooledge
Message-ID: <20190329124148.a3t3xkze4btsk...@eeg.ccf.org>
| But perhaps you're right about the letter C specifically.
I was, because that was the character of relevance in the bug
report, and solving (or inven
Date:Mon, 08 Apr 2019 17:04:41 -0700
From:L A Walsh
Message-ID: <5cabe199.9030...@tlinx.org>
| On 4/8/2019 7:10 AM, Chet Ramey wrote:
| > Pipes are objectively not the same as files. They
| >
| > 1. Do not have file semantics. For instance, they are not seeka
Date:Mon, 8 Apr 2019 22:03:25 -0700
From:pepa65
Message-ID:
| What is nice about here docs/strings is that there are no subshells
| involved.
When they use files, that's correct, but when a pipe is used, unless
the data size is both known in advance, and limited
Date:Mon, 8 Apr 2019 23:36:39 -0700
From:pepa65
Message-ID:
| When in the past I proposed this syntax:
| cmd >>>var
| the idea was to commit the output of a command into memory (in the form
| of a variable), without requiring a pipe or file.
In general
Date:Thu, 11 Apr 2019 06:02:41 +0200
From:"Jason A. Donenfeld"
Message-ID:
| Now, it might be the case that bash really isn't the
| right tool for that kind of thing, and I shouldn't use bash for tasks
| with security requirements as such. But I sort of love
Date:Thu, 11 Apr 2019 19:05:56 -0400
From:Chet Ramey
Message-ID: <6973cbca-28bd-5a20-4966-1d8251e95...@case.edu>
| If you want to be sure to shift out all existing parameters, use
| `shift $#'. If you want something else, you can add logic to cap the
| argument
Date:Mon, 15 Apr 2019 09:19:19 -0400
From:Greg Wooledge
Message-ID: <20190415131919.gy6...@eeg.ccf.org>
| > > setupargs="$@"
| Also, you are squashing all of your filename arguments down into a
| single string variable,
This is simply an unspecified o
Date:Tue, 16 Apr 2019 10:29:36 +0800
From:Paul Wise
Message-ID: <5be7a3060ecb029ac36a4592bbee7fc071becd12.ca...@bonedaddy.net>
| I wonder if bash could set an additional variable to indicate if $? is
| from a normal exit, a signal exit, a shell keystroke etc,
Tha
Date:Tue, 23 Apr 2019 15:49:18 -0600
From:Ian Neal
Message-ID:
| When using arithmetic expansion with variable pre- and
| post-increments/decrements in the output redirection file path,
| specifically on external executables (not builtins or functions), the st
Date:Tue, 21 May 2019 22:11:20 +
From:Charles-Henri Gros
Message-ID:
| The existence or not of the file should not have any effect.
But it does, and is intended to. If the mattern matches a file
(when patyhname expanded as a result of the unquoted command s
Date:Wed, 22 May 2019 08:43:00 -0400
From:Greg Wooledge
Message-ID: <20190522124300.gz1...@eeg.ccf.org>
| It seems to be unique to bash 5. If it's a bug fix, then I'm not
| understanding the rationale. Backslashes shouldn't be consumed during
| glob expansion.
Date:Wed, 22 May 2019 17:34:22 +
From:Charles-Henri Gros
Message-ID:
| The problem I'm trying to solve is to iterate over regex-escaped file
| names obtained from a "find" command. I don't know how to make this
| work. It works with other versions of bash
Date:Wed, 22 May 2019 22:23:04 +
From:Charles-Henri Gros
Message-ID:
| But unfortunately, grep was just illustrative, I'm using another tool
| that takes a regex but has no "-F" option (though admittedly with some
| effort I could add one, I wrote the tool
Date:Thu, 6 Jun 2019 09:57:24 +0200
From:mwnx
Message-ID: <20190606075724.GA9670@noisy>
| After all, it does wait for all other
| kinds of processes irrespective of when they were started or how
| many there are,
Shells aren't required to keep track of any proc
Date:Tue, 09 Jul 2019 20:24:30 -0700
From:L A Walsh
Message-ID: <5d255a6e.4060...@tlinx.org>
| Why? What makes clarity "horrible".
It isn't the clarity (if you call it that, it is really obscurity
as no-one else can read your scripts/commands and have any idea
Date:Wed, 10 Jul 2019 05:01:28 -0700
From:L A Walsh
Message-ID: <5d25d398.7010...@tlinx.org>
| You are going to tell me that saying
| int i=1 is too obscure to be deciphered by most, versus
| declare -i i=1;
People can guess at the first, for the second, they c
Date:Wed, 10 Jul 2019 09:01:28 -0700
From:L A Walsh
Message-ID: <5d260bd8.8010...@tlinx.org>
| What do you think aliases are?
I know exactly what aliases are. (I could just say "useless" but
that's a different kind of what they are than you mean.)
| They are b
Date:Wed, 10 Jul 2019 19:46:58 -0700
From:L A Walsh
Message-ID: <5d26a322@tlinx.org>
| But it was what I was thinking when I said they were the same.
None of us are mind readers, we cannot know what you were thinking,
only what you said (typed). If you're
Date:Fri, 12 Jul 2019 10:22:18 -0700
From:L A Walsh
Message-ID: <5d28c1ca.3000...@tlinx.org>
| They are both substitution mechanisms.
No, they're not. The hash table is an optimisation which speeds the
search for the pathname of a command, and that's all - every
Date:Wed, 10 Jul 2019 17:21:00 +
From:astian
Message-ID:
I doubt it makes any difference to the timing, which I think
Chet has already answered, but it is worth pointing out that these
two commands ...
printf '%s\n' "`printf %s "$i"`"
The ulimit usage lists all the limits that bash supports.
Of those, the ones that actually work are the ones that your
system also supports.
On my system (like yours) ulimit -P and ulimit -k fail, as
while the system has pseudo tty's and kqueues, there are no
per process limits on how many can be
Date:Mon, 29 Jul 2019 01:02:37 -0700
From:L A Walsh
Message-ID: <5d3ea81d.4020...@tlinx.org>
| I didn't see this come back from the list and it was sent
| 45 minutes ago (vs. other emails of mine that have come
| back in under a minute).
| Did anyone else see
ps: if you want to find out which ulimit options
are supported on your system, use (parse) the output
of ulimit -a
Modified script that does that appended .. still
bash specific, as the output format of ulimit -a is
also not specified ... in fact, giving any options to
ulimit at all, aside from -f
Date:Tue, 30 Jul 2019 00:46:38 -0700
From:L A Walsh
Message-ID: <5d3ff5de.50...@tlinx.org>
| It isn't a judgment call to list only the options it supports on a given
| system. I'd think that would be clear.
That's an opinion, and that makes it something which ev
Date:Mon, 05 Aug 2019 14:05:43 +0200
From:Steffen Nurpmeso
Message-ID: <20190805120543.bf9-u%stef...@sdaoden.eu>
| Would be nice to have some shell support for signalling the parent
| that the child is now functional,
The shell cannot really know - your example w
Date:Tue, 6 Aug 2019 16:00:21 -0400
From:Greg Wooledge
Message-ID: <20190806200021.gk1...@eeg.ccf.org>
| Unquoted $a is a bad idea, which
| may explain why it didn't receive enough testing to uncover whatever
| this is.
A sane person might do it if
a=fo
Date:Sat, 21 Sep 2019 17:18:47 +0200
From:Andreas Schwab
Message-ID: <875zllu17s@igel.home>
| A job spec already starts with %.
That's not what was meant.
In, for example:
jinx$ help -s wait
wait: wait [-fn] [id ...]
the command name appears
Date:Mon, 23 Sep 2019 12:29:18 +0300
From:Ilkka Virta
Message-ID: <59cf49b0-1292-b752-4fe8-8928fd558...@iki.fi>
| (as well the standard '-depth', somewhat confusingly)
There is no real standard for this - NetBSD has deprecated the -depth
operator (which never reall
Date:Mon, 23 Sep 2019 16:36:59 +0200
From:Andreas Schwab
Message-ID:
| According to https://www.freebsd.org/cgi/man.cgi, find -d already
| appeared in 4.3BSD, and -depth is much newer.
I can believe that, I did not research the history, just what is in
the NetBS
Date:Mon, 23 Sep 2019 10:59:43 -0400
From:Greg Wooledge
Message-ID: <20190923145943.gx28...@eeg.ccf.org>
| But... there literally *is* a real standard for this.
Hmm, yes, you're right. That suggests that -depth must be a System-V
invention (POSIX wouldn't have ad
Date:Mon, 23 Sep 2019 14:12:27 -0400
From:Chet Ramey
Message-ID: <49989bf9-7c12-2670-de3f-20feead50...@case.edu>
| It's in SVR2 (1984?), at least,
Thanks.
| The SVR2 page implies that it was added to support cpio.
Yes .. the function of the option is fine - whe
Date:Sat, 9 Nov 2019 00:50:52 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
These two
| v=foo
| echo ${v#[[:"lower":]]}
| case foo in (*[![:"lower":]]*) echo bar; esac
are because bash believes that the character class name must not
be quoted (which is likely
Date:Sat, 9 Nov 2019 07:35:16 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| is correct, as "foo" does not contain a ']' which would be required
| > to match there (quoting the ':' means there is no character class,
| > hence we have instead (the negation of) a
Date:Sat, 09 Nov 2019 06:46:05 -0800
From:L A Walsh
Message-ID: <5dc6d12d.6040...@tlinx.org>
| Is this really what the standard says,
Yes, I used cut&paste (and then some line length/wrappoing reformatting)
| because '\\' is not a character, but 2 characters.
I
Date:Sat, 9 Nov 2019 16:39:52 +0100
From:Davide Brini
Message-ID: <1mi5ud-1ifip305pl-00f...@mail.gmx.com>
| If you want to force base 10 interpretation (remember that leading 0 mean
| octal in arithmetic context), you need to explicitly tell bash:
|
| $ echo $
Date:Tue, 19 Nov 2019 16:51:12 -0300
From:Luiz Angelo Daros de Luca
Message-ID:
| And two related features requests: 1) It seems that pids args are ignored
| by wait when '-n' is specified. However, it would be a nice add_on to use
| the list of pids as a filt
Date:Thu, 21 Nov 2019 10:27:08 +0800
From:Clark Wang
Message-ID:
| So is it OK to not change $? when people are pressing CTRL-C to
| discard the input?
I would say not only "OK" but "required" - $? should only ever be
changed as a result of command execution (o
Date:Fri, 22 Nov 2019 16:16:58 +0800
From:Clark Wang
Message-ID:
| Curious why people care about this?
For some people it seems to be related to wanting to see $? in their
prompt, and either have it explicit that a SIGINT interrupted command
entry, or continue wi
Date:Mon, 25 Nov 2019 13:43:41 -0800
From:Peter Benjamin
Message-ID:
<4dc457e0135603025cd500acdc95db53f9d30482.ca...@peterbenjamin.com>
| Description:
| 'in' is a builtin command and is not listed in the man page as such.
Others have indicated what it is, but j
Date:Mon, 25 Nov 2019 16:47:23 +0200
From:IFo Hancroft
Message-ID:
| I don't remember it on top of my head but IIRC it doesn't change the title.
In an xterm (maybe other things, sine many of them copied) \e]2; ...
sets the title. I do it that way in my (farily
Date:Mon, 25 Nov 2019 19:13:19 -0800
From:Peter Benjamin
Message-ID:
<14db6b9f69f249db60a0f92df80339d88efba152.ca...@peterbenjamin.com>
| Only those RESERVED WORDS when tried at the CLI, alone, that generate a
| 'confusing' error message,
It is possible for some
Date:Fri, 6 Dec 2019 05:53:04 +0100
From:Martin Schulte
Message-ID: <20191206055304.076d6115afa3a4f2a6a21...@schrader-schulte.de>
| Yes - sure. But then I'm wondering why the unquoted backtick doesn't
| start command substitution:
Too late. Syntax elements must
Date:Sat, 14 Dec 2019 02:48:16 -0800
From:L A Walsh
Message-ID: <5df4bdf0.6000...@tlinx.org>
| it could break existing scripts that
Scripts should not be using brace expansion in the first place, it
is useful to save typing for interactive shells, but (whatever quo
Date:Wed, 18 Dec 2019 19:40:45 -0400
From:Bize Ma
Message-ID:
| A little delay seems to get it working:
|
| $ echo value | { read -t 0 var; } ; echo $?
| 0
It might, but that is adding no significant delay, and the
results are unpredictable.
jinx$ echo val
Date:Tue, 24 Dec 2019 00:47:40 -0500
From:Eli Schwartz
Message-ID: <217b4a75-b79e-dc2a-a2b2-cc5133d7c...@archlinux.org>
| What is "recent" about sort -u? I can find it listed as a mandatory
| option in the POSIX 2004 manual.
The -u option appaeared in 7th edition
Date:Tue, 24 Dec 2019 12:16:41 -0500
From:Eli Schwartz
Message-ID:
| Hmm, is that "more or less" the same, or actually the same?
It depends what other options are given (to each). With no options at all
they are probably the same.
kre
Date:Thu, 9 Jan 2020 12:09:22 +0100
From:Mickael KENIKSSI
Message-ID:
| zsh (and ksh) provide the expected result:
As far as I can tell, all shells except bash preserve the
null components, regardless of whether or not pattern chars
appear in filenames to the rig
Date:Tue, 28 Jan 2020 16:02:25 -0500
From:Roger
Message-ID: <20200128210225.GC12574@localhost4.local>
| 1) Bash internal reserved words cannot be used a variables.
No such rule. Vars are always assigned using xxx= (no reserved words
contain an '=') and accessed u
Date:Tue, 28 Jan 2020 16:25:51 -0500
From:Roger
Message-ID: <20200128212551.GD12574@localhost4.local>
| Wow, " trap 'trap INT; kill -INT $$' INT " not easily readable for me.
You can often help with things like that by reformatting
trap '
Date:Wed, 29 Jan 2020 09:23:05 -0500
From:Greg Wooledge
Message-ID: <20200129142305.gx1...@eeg.ccf.org>
| As far as functions go, bash allows you to define local variables within
| a function. This avoids namespace collisions as long as you're within
| that fun
Date:Wed, 29 Jan 2020 13:57:48 -0500
From:Greg Wooledge
Message-ID: <20200129185748.gf1...@eeg.ccf.org>
| A script is supposed to be a self-contained entity, as much as possible.
| It isn't supposed to be part of some web of tangled dependencies.
In general I agr
Date:Thu, 6 Feb 2020 19:29:41 +
From:Harald van Dijk
Message-ID:
| Nice test.
Yes!
| and the various ash-based shells do not unblock it.
We do now, the fix for that will be in 9.0 when it is released.
("now" as in as of the past half hour...)
| Because
Date:Thu, 6 Feb 2020 16:12:06 +
From:Martijn Dekker
Message-ID: <10e3756b-5e8f-ba00-df0d-b36c93fa2...@inlv.org>
| NetBSD sh behaves differently. NetBSD 8.1 sh (as installed on sdf.org
| and sdf-eu.org) seem to act completely normally, but NetBSD 9.0rc2 sh
Date:Tue, 18 Feb 2020 17:46:23 +0100
From:Denys Vlasenko
Message-ID:
| > If NetBSD sh
| > manages to avoid this pattern, and assuming NetBSD sh is not still
| > susceptible to one of those race conditions
|
| Please let us know what you discovered.
It is
Date:Wed, 19 Feb 2020 23:53:56 +
From:Harald van Dijk
Message-ID: <9b9d435b-3d2f-99bd-eb3d-4a676ce89...@gigawatt.nl>
| POSIX says in the description of the trap command "Otherwise, the
| argument action shall be read and executed by the shell when one of the
Date:Thu, 20 Feb 2020 09:16:05 +
From:Harald van Dijk
Message-ID:
| In that case, I think we can interpret the "when" in the description
| of the trap command literally except when 2.11 overrides it.
I think it should be interpreted just like its normal Engl
Date:Fri, 21 Feb 2020 10:07:25 -0500
From:Chet Ramey
Message-ID:
| That's just not reasonable. You're saying signals that are received before
| the wait builtin begins executing (say, while the command is being parsed,
| or the shell is doing some other bookkee
Date:Mon, 24 Feb 2020 11:50:55 +0100
From:Denys Vlasenko
Message-ID: <47762f41-e393-30cd-50ed-43c6bdd29...@redhat.com>
| This is racy. Even if you try to code is as tightly as possible:
Absolutely, I agree. The question is more whether it really matters.
| Sta
Date:Mon, 24 Feb 2020 04:58:31 -0800
From:"Daniel Colascione"
Message-ID: <07d1441d41280e6f9535048d6485.squir...@dancol.org>
| That is a poor excuse for not fixing bugs.
Only if they are bugs.
| Maybe you can torture the standards into confessing that this
Date:Mon, 24 Feb 2020 06:44:12 -0800
From:"Daniel Colascione"
Message-ID:
| That executing traps except in case you lose one rare race is painfully
| obvious.
Maybe you misunderstand the issue, no traps are lost, if they were
that would indeed be a bug, the trap
Date:Mon, 9 Mar 2020 20:28:30 +0059.55
From:Martin Castillo
Message-ID: <5ad25080-7c13-9b9c-cff6-12ffee7af...@uni-bremen.de>
| Repeat-By:
| $ unset foo bar
| $ echo "${foo:=}/baz:${foo}/bat"|xxd
| : 7f2f 6261 7a3a 2f62 6174 0a ./baz:/bat.
Date:Fri, 13 Mar 2020 06:59:56 -0500
From:John McKown
Message-ID:
| I do things like:
|
| test && { true_command1;true_command2; : ; } || {
| false_command1; false_command2; false_command3; }
That's OK, and at times I have been tempted that way, but it re
Date:Sat, 4 Apr 2020 08:32:57 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| While waiting for read builtin to complete, bash executes signal handlers
| in a subshell where signals are ignored. See below.
|
| $ foo() { trap foo INT; read; }
What that says, i
Date:Sun, 5 Apr 2020 05:06:56 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| I was expecting it to work (i.e interrupt read again and call foo)
Isn't that what it did?
But I see what you mean now, during the read that's called from the
trap execution call of foo,
Date:Sun, 5 Apr 2020 16:21:53 -0400
From:Chet Ramey
Message-ID: <45c766ba-4489-bd7b-40c7-32fed3746...@case.edu>
| That's not how read is defined to behave. wait has special wording defining
| what happens when it receives a signal.
No, it doesn't, that's a misrea
Date:Mon, 6 Apr 2020 15:06:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Or, is it that when job controls are enabled each synchronous command is
| run in its own process group and SIGINT is not sent to the shell at all?
That would be correct.
kre
ps: the
Date:Mon, 6 Apr 2020 10:10:47 -0400
From:Chet Ramey
Message-ID: <3e31254d-cc8b-221c-ddb9-ea1ea9fa7...@case.edu>
| I wonder if we're talking about the same thing.
We weren't, but it makes little difference.
| I'm talking about how the
| standard says wait will
Date:Mon, 6 Apr 2020 15:44:08 -0400
From:Chet Ramey
Message-ID: <20735a7e-627d-763b-adf6-0d94203aa...@case.edu>
| You mean the terminal's input buffer, or readline's line buffer with
| characters it's already read?
As a user I don't distinguish the two cases. A
Date:Fri, 17 Apr 2020 16:12:20 -0400
From:Chet Ramey
Message-ID: <4bacf2f0-9802-67d3-f30b-80e37d058...@case.edu>
| I would say this is a programmer error. The way precisions work with
| string arguments is that the argument is fetched or generated (this
| inclu
Date:Sun, 19 Apr 2020 15:40:39 -0400
From:Chet Ramey
Message-ID: <8c5bdd2c-bc61-a885-6a05-690ef7f51...@case.edu>
| Nobody, including POSIX, is rational, then.
There is no %q in POSIX printf currently, so the issue
does not arise there, and in any case, its objectiv
Date:Mon, 20 Apr 2020 09:03:39 -0400
From:Chet Ramey
Message-ID: <51b585da-b594-740d-1772-3c3a25a89...@case.edu>
| I'm referring to the specification of %b that I quoted in another message,
I didn't see that (and I certainly didn't comment on it wrt rationality).
Date:Mon, 27 Apr 2020 22:03:47 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87pnbsfjss@hobgoblin.ariadne.com>
| While I was looking at the details of parsing function definitions, I
| tripped on something I should have noticed long ago. In the
Date:Sun, 3 May 2020 08:28:30 +0200
From:Tobias Wendorff
Message-ID:
| When creating a here document containing the greater-than sign followed
| by number sign, newlines get added to Bash history:
The example given showed a less than, rather than greater than,
b
Date:Sun, 3 May 2020 15:58:59 +0200
From:Tobias Wendorff
Message-ID: <0c8f8899-0421-0aa7-2ecd-2167018c3...@gmx.de>
| Is this behavior planned or unplanned? The problem doesn't seem to
| appear on Bash 4 (Debian Jessie, Cygwin on Windows).
Not for me to say, but I
Date:Mon, 4 May 2020 08:58:08 -0400
From:Chet Ramey
Message-ID:
| The command-oriented history mode has to pay attention to those, ['#']
| because shell comments are one place where you can't
| replace a newline with a semicolon.
That makes sense.
| It ju
Date:Thu, 28 May 2020 15:12:47 -0700
From:Keith Thompson
Message-ID:
| Program received signal SIGSEGV, Segmentation fault.
| 0x7777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2
| (gdb) where
| #0 0x7777eddb in ?? () from
/l
Date:Sun, 31 May 2020 10:29:27 +0100
From:Laurent Picquet
Message-ID:
| This behaviour is not fully documented
Nothing is ever "fully" documented, as it is always possible to
write even more text about anything at all - and if that were done
then it is clear that
Date:Mon, 1 Jun 2020 09:16:17 -0400
From:Eli Schwartz
Message-ID: <031b5b39-826a-6523-b03b-b839efe9e...@archlinux.org>
| I could not figure out whether the grammar allowed
| or forbade this this result.
It isn't the grammar, that would affect syntax, it is the s
Date:Sun, 31 May 2020 22:46:48 -0400
From:Eli Schwartz
Message-ID: <5a7df0ba-3ad1-1f35-1107-09fdd5950...@archlinux.org>
While I generally agree with ...
| Don't use errexit
but not really with:
| it does not mean what you think it does.
(it does mean what I th
Date:Mon, 8 Jun 2020 09:34:34 -0400
From:Greg Wooledge
Message-ID: <20200608133434.ga4...@eeg.ccf.org>
| Those are not standard vi commands, as far as I can tell.
You're right, they're not.
| g$ acts just like $.
| g0 acts just like 0.
| gE acts just like E
Date:Thu, 25 Jun 2020 10:46:01 -0700
From:L A Walsh
Message-ID:
| But that wouldn't follow the email response instructions of posting your
| response above the previous email
I don't always agree with Greg, but this time I do: whoever or whatever
issued those i
Date:Sun, 28 Jun 2020 12:06:10 -0400
From:Eli Schwartz
Message-ID:
| You COMPLETELY failed to even read the reporter's message, which
| specifically stated "In order to reduce forks and make some tasks a lot
| quicker [...]"
I noticed that explanation, but li
Date:Sun, 28 Jun 2020 15:19:27 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87h7uv0zi8@hobgoblin.ariadne.com>
| For a long time, I've wanted a variant of -x that only echoed the simple
| commands after bash is done executing the startup files.
301 - 400 of 598 matches
Mail list logo
