Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.
On Fri, Apr 26, 2024 at 4:57 AM Dan Shelton wrote:
> Could you do this for the next alpha release, please?
Run `find -name Makefile -exec sed -i 's/\$[({]MFLAGS[)}]//g' {} +'
and it'll work. What's the hurry?
Re: [5.3-alpha] ">& /some/file" would fail when /some/file already exists
On Fri, Apr 26, 2024 at 1:17 AM Grisha Levit wrote: > Actually, I see this on Ubuntu 22.04 but not on macOS. On Linux, O_EXCL and RX_EXPANDED (a flag used by bash to signal that the redirection word is already expanded) has the same value. I don't know why bash doesn't clear its internal flags before calling open.
Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}
On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote: > I cannot find anything in the manual that concretely explains why bash > behaves as it does in this instance. Me neither, but the current behavior is useful. Take `while false | false; do :; done' for example, if bash reported the status of the while command in PIPESTATUS you couldn't tell which part of your condition failed. This isn't reliable when the lastpipe shell option is in effect and you have `some command | break' in your loop body but I've never seen anything like that in a real shell script.
Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.
On Monday, April 22, 2024, Dan Shelton wrote: > Passing -j to submakes ist just wrong. All submakes and the parent > should be part of ONE GNU make jobserver. > Is MFLAGS used for anything other than compatibility with ancient makes? Why doesn't GNU make just strip the j flag from it? -- Oğuz
Re: Exporting functions does not expand aliases in subshells
On Thursday, April 11, 2024, Kerin Millar wrote: > > Notwithstanding, I tried declaring the same function in an interactive > instance of dash and found that the alias within the command substitution > does end up being expanded, which is in stark contrast to the behaviour of > bash. > Bash's behavior matches that of dash in POSIX mode. This is documented here in the 8th item https://tiswww.case.edu/php/chet/bash/POSIX -- Oğuz
Re: Potential Bash Script Vulnerability
On Tue, Apr 9, 2024 at 5:17 AM Robert Elz wrote: > Sure, it is possible to make a useless program like this ... > Almost all real commands use stdio to read stdin. Playing about > any more with this absurd example isn't worth the bother. The relevant > text should simply be deleted from POSIX. It is bizarre and unnecessary. Using stdio to read stdin doesn't stop you from detecting if it is connected to a file and adjusting the file offset before exit. In fact, POSIX mandates that for standard utilities in XCU 1.4 Utility Defaults, INPUT FILES section: When a standard utility reads a seekable input file and terminates without an error before it reaches end-of-file, the utility shall ensure that the file offset in the open file description is properly positioned just past the last byte processed by the utility. For files that are not seekable, the state of the file offset in the open file description for that file is unspecified. A conforming application shall not assume that the following three commands are equivalent: tail -n +2 file (sed -n 1q; cat) < file cat file | (sed -n 1q; cat) The second command is equivalent to the first only when the file is seekable. The third command leaves the file offset in the open file description in an unspecified state. Other utilities, such as head, read, and sh, have similar properties. If the shell doesn't cooperate with other utilities in this, this can happen: $ cat tst.sh echo hi sed -n 1q # Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla gravida odio # ultrices, consectetur libero eu, malesuada augue. Proin commodo faucibus ipsum # et viverra. In dictum, risus eu hendrerit rutrum, lorem diam cursus sapien, # nec mollis urna nunc non enim. Etiam at porttitor neque. Quisque elementum # orci in nisi egestas, sit amet pretium est tincidunt. Pellentesque eleifend # nec tellus eu lobortis. Praesent pharetra sed neque eleifend interdum. # # Aenean eget tincidunt sem. Etiam ac ultricies leo. Nunc tortor ante, finibus # in ullamcorper id, mattis sit amet ipsum. Etiam ac diam sem. Aenean a purus # ex. Proin tincidunt erat odio, ut suscipit purus commodo nec. Curabitur eget # ante non mi sagittis congue ac non massa. Cras tincidunt bibendum erat, ut # gravida arcu congue eu. Phasellus ex quam, blandit at interdum at, cursus eu # nisi. Nullam interdum faucibus massa at luctus. Nullam eu sapien ut mauris # eleifend pharetra sit amet quis ante. Nullam porttitor enim eros, e if false; then rm uh-oh fi $ $ busybox sh
Re: Potential Bash Script Vulnerability
On Mon, Apr 8, 2024 at 5:32 PM Robert Elz wrote: > The effect is that sharing stdin between the shell script, and other > commands (than read), is almost certainly never going to work, Why not? It works fine with other shells $ cat tst.sh cat
Re: Potential Bash Script Vulnerability
On Mon, Apr 8, 2024 at 5:58 AM Robert Elz wrote: > Shells interpret their input in much the same way, regardless of > from where it comes. Would you really want your login shell to > just collect commands that you type (possibly objecting to those > with syntax errors) but executing none of them (including "exit") > until you log out (send EOF) ? On a related note, POSIX says this: When the shell is using standard input and it invokes a command that also uses standard input, the shell shall ensure that the standard input file pointer points directly after the command it has read when the command begins execution. It shall not read ahead in such a manner that any characters intended to be read by the invoked command are consumed by the shell (whether interpreted by the shell or not) or that characters that are not read by the invoked command are not seen by the shell. So this command sh <
Re: Bug tracking
On Monday, April 1, 2024, Martin D Kealey wrote: > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > Are we building a cathedral with gatekeepers, or a bazaar > where the masses can contribute? > What's stopping masses from contributing now? All you need is an email address. And why this non-stop nagging? If you want maintainership ask for it, or is your plan boring us all to death first? -- Oğuz
Debian bug #929178: wrong trap displayed inside functions
On Tuesday, March 26, 2024, Martin D Kealey wrote: > > When forwarding incoming HTML to a text-only list, most mailing list > servers will put the hyperlinks in a footnote, so that that long links > won't obscure the text they apply to. (The better ones only do this when > text text and its hyperlink differ; if the text and its hyperlink match > (like when you have XX for any XX) then nothing is gained > by duplicating it. That would appear to be the case with this mailing > list.) > > Some mail receivers (e.g. Gmail) will convert bare text that looks like a > hyperlink back into a hyperlink, which is how you get clickable links in > the footnote. > They don't actually type those brackets then. Thanks -- Oğuz
Re: Debian bug #929178: wrong trap displayed inside functions
On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson wrote: > [1] > [1] http... I keep seeing this. Why don't you guys just paste the link?
Debian bug #929178: wrong trap displayed inside functions
On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. dash doesn't even support `x=$(trap)', which is mandated by POSIX to work; and busybox sh is a bare-bones shell for small, embedded systems. -- Oğuz
Debian bug #929178: wrong trap displayed inside functions
On Monday, March 25, 2024, Gioele Barabucci wrote: > > If a function does not set a trap, `trap` will output the command set by > the caller. This is just a cosmetic issue, the right trap will be run at > runtime. > Doesn't POSIX allow this? How else do you propose we save the trap set for an event into a variable if `x=$(trap)' stops working? -- Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Oğuz wrote:
>
> $ printf '%s\0' "${a[@]@k}" | xargs -0 jq --args -n '$ARGS.positional
> | _nwise(2) | {(.[0]): .[1]}' | jq -s add
>
On reflection, splitting by NULs in JQ is better; there is no guarantee
that xargs will always provide an even number of arguments.
--
Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Greg Wooledge wrote:
> Conceptually that looks great, but how do you avoid "Argument list
> too long" with larger inputs?
$ declare -A a=([x]=1 [y]=2)
$ printf '%s\0' "${a[@]@k}" | xargs -0 jq --args -n '$ARGS.positional |
_nwise(2) | {(.[0]): .[1]}' | jq -s add
{
"y": "2",
"x": "1"
}
--
Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Zachary Santer wrote:
>
> Yeah, but what can you do with @k?
It helps when reconstructing an associative array as a JSON object in JQ
$ declare -A a=([x]=1 [y]=2)
$ jq --args -n '[$ARGS.positional | _nwise(2) | {(.[0]): .[1]}] | add'
"${a[@]@k}"
{
"y": "2",
"x": "1"
}
--
Oğuz
Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell
On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: > The command in the first shell will exit after a random number of > iterations with "terminated with exit status 141". That's what every other shell does. > Regardless of the reason for the SIGPIPE, the reporter expects the loop > to carry on indefinitely (`while true; ...`). Then he should do `trap '' PIPE' before the loop. > > it is incorrect that > SIGPIPE terminates the subshell. Why?
Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
On Sunday, March 17, 2024, tpeplt wrote: > >The texinfo version of the bash manual is missing a description of > the ‘shopt’ option ‘syslog_history’. > That must be a vendor extension, bash doesn't have such an option. -- Oğuz
Re: declare -f does not output esac pattern correctly
On Tuesday, February 27, 2024, Martin D Kealey wrote: > > I've been thinking for a while now that POSIX made a mistake when it > permitted ';;' before the closing 'esac'. > I think that decision was made before POSIX. Besides it's handy when generating case clauses on the fly, you may not always know which case is going to be the last. You may not always know that at least one clause is going to be generated either, but `case x in esac' is valid, so it's not a problem. The syntax for the case command is neat as-is. -- Oğuz
Re: [PATCH] tests/array.tests: using grep -E instead of egrep
On Monday, February 19, 2024, Lawrence Velázquez wrote: > > On what system does this happen? The proposed changes might break the > test suite on some older systems. > Agreed. Those egrep invocations can be replaced with `grep -v -e BASH_VERSINFO -e PIPESTATUS -e GROUPS' though. -- Oğuz
Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )
On Tuesday, February 6, 2024, Chet Ramey wrote: > > What's the specific request here? > That bash interpret multiline commands retrieved from command history as a whole and not run the rest of the lines as separate commands when the first line is changed. Try it yourself; run a multiline command, recall it and edit the first line to introduce a syntax error and hit enter. Does it look right? Wouldn't it be much better if the entire command were discarded? -- Oğuz
Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )
On Sunday, February 4, 2024, Zachary Santer wrote: > > While I'm making feature requests. > I want to make one too. Multiline commands retrieved from history can be short-circuited like this: $ ls x y $ echo ' > rm * > ' >z $ $ ls x y z $ echo '' rm * ' >z > ^C $ ls $ After the second invocation of `ls' I add a single quote and hit enter accidentally, and lose all my files. I wish it didn't happen -- Oğuz
Re: wait -n misses signaled subprocess
On Monday, January 29, 2024, Greg Wooledge wrote: > > Anyway... a script writer who has a basic familiarity with wait(2) and > who reads about "wait -n" will probably assume that wait -n will return > immediately if a child process has already terminated and hasn't been > "pseudo-reaped" by a previous "wait" command yet. If three children > have terminated, then the next three "wait -n" commands should return > immediately, and the fourth should block (assuming a fourth child exists). > This is the case with me. There is no point in having `wait -n' if it can't distinguish a single job terminating from multiple jobs terminating between subsequent calls. -- Oğuz
Re: cd"": Shouldn't it fail?
On Sunday, January 28, 2024, Kerin Millar wrote: > To summarise, the behaviour of bash appears to conform with the wording of > Issue 7 but it may have to change for Issue 8 or a later revision. > Yeah I think you're right. In the description of directory operand, Issue 7 says: >If *directory* is an empty string, the results are unspecified. This changes to the following in Issue 8 draft 4: >If directory is an empty string, cd shall write a diagnostic message to standard error and exit with non-zero status. Sorry for the noise. -- Oğuz
Re: cd"": Shouldn't it fail?
On Sun, Jan 28, 2024 at 5:10 PM wrote: > POSIX Programmer's Manual (cd(1p) manpage) says this: > > [9 unrelated special cases] > > 10. The cd utility shall then perform actions equivalent to the >chdir() function called with curpath as the path argument. If >these actions fail for any reason, the cd utility shall >display an appropriate error message and the remainder of >this step shall not be executed. [...] Right before that, it says in 8.c: > If, as a result of this canonicalization, the curpath variable is null, no > further steps shall be taken. which is what happens in bash, busybox sh, dash, mksh, pdksh, oksh, yash, zsh, and NetBSD sh.
Re: wait -n misses signaled subprocess
On Mon, Jan 22, 2024 at 8:13 PM Steven Pelley wrote:
>
> Hello,
> I've encountered what I believe is a bug in bash's "wait -n". wait -n
> fails to return for processes that terminate due to a signal prior to
> calling wait -n. Instead, it returns 127 with an error that the
> process id cannot be found. Calling wait (without -n) then
> returns its exit code (e.g., 143). I expect wait -n to return each
> process through successive calls to wait -n, which is the case for
> processes that terminate in other manners even prior to calling wait
> -n.
I agree that this is a bug in bash.
jobs.c/wait_for_any_jobs() marks all dead jobs as notified after
reporting the status of the first one and misses the rest. With the
following change (not a real fix, just for demonstration), devel
branch behaves as expected:
diff --git a/jobs.c b/jobs.c
index 3e68bf24..d7c8d11b 100644
--- a/jobs.c
+++ b/jobs.c
@@ -3257,7 +3257,7 @@ wait_for_any_job (int flags, struct procstat *ps)
{
if ((flags & JWAIT_WAITING) && jobs[i] && IS_WAITING (i) == 0)
continue; /* if we don't want it, skip it */
- if (jobs[i] && DEADJOB (i) && IS_NOTIFIED (i) == 0 &&
IS_FOREGROUND (i) == 0)
+ if (jobs[i] && DEADJOB (i) && IS_FOREGROUND (i) == 0)
{
return_job:
r = job_exit_status (i);
Re: ./script doesn't work in completion function
On Mon, Jan 22, 2024 at 3:25 PM Greg Wooledge wrote: > But in any case, writing a "script" without a shebang and then counting > on the shell to work around the broken script is not ideal. Unlike shebangs that behavior is standardized. Which is what I consider ideal. Thanks for your input
Re: ./script doesn't work in completion function
On Monday, January 22, 2024, Martin D Kealey wrote: > > You seem to have created an invalid executable. It seems that scripts > without a #! can only be run with help from the debugger library > Hi Martin, POSIX shells interpret such executables as shell scripts, I don't think bash would take a hacky approach like that for implementing this basic functionality. It must be something else -- Oğuz
./script doesn't work in completion function
See:
$ echo echo foo bar >s
$ chmod +x s
$ f(){ COMPREPLY=($(bash ./s));}
$ complete -F f g
$
$ g
bar foo
$ g ^C
$
$ f(){ COMPREPLY=($(./s));}
$ g ^C^C
$
I press tab after typing `g ' in both cases, this moves the cursor to
the right in the second case instead of showing the completion
options.
This is reproducible on both the devel branch and 5.1.16, I didn't test 5.2.
Oğuz
Re: nofork command substitution bugs
On Fri, Jan 12, 2024 at 7:05 PM Chet Ramey wrote:
> Nofork command substitution freezes the jobs list, because you don't
> want jobs appearing and disappearing in the list while you're running
> word expansion. If the jobs list is frozen, wait -n doesn't even try
> waiting, since you don't want jobs removed from the list in, say, a
> SIGCHLD trap. I think it's ok to do the wait but not delete the job,
> regardless of what posix says, so I'll make that change for funsubs.
Sounds good, thanks.
> Why would that be unexpected, since you're explicitly running something
> in the calling shell's context, with the expected side effects to that
> environment?
I wasn't clear. This doesn't exit the shell
bash-5.3$ exec foo
bash: exec: foo: not found
bash-5.3$
This does:
bash-5.3$ : ${ exec foo;}
bash: exec: foo: not found
$
Why would you expect either to cause an interactive shell to exit?
nofork command substitution bugs
These bugs affect the development branch only.
1. `wait -n' doesn't work inside nofork command substitution. I think
it should, or wait without `-n' shouldn't work either, or what works
and what doesn't should be documented.
$ sleep 3 & sleep 1; echo ${| wait -n -p REPLY;}
[1] 433
$
[1]+ Donesleep 3
$
2. Sending a signal other than SIGTERM to an asynchronous process
created inside nofork command substitution kills the parent shell.
This should not happen.
$ trap uname EXIT
$ : ${ dd if=/dev/zero of=/dev/null &}; sleep 1; kill -USR1 %
4730333+0 records in
4730333+0 records out
2421930496 bytes (2.4 GB, 2.3 GiB) copied, 1.00056 s, 2.4 GB/s
Linux
User defined signal 1
$
There are other cases where the parent shell exits unexpectedly, such
as when the exec command fails inside nofork command substitution, but
I'm not sure if those are bugs or intended behavior.
3. Linking REPLY to a variable inside nofork command substitution
renders the target variable unset. I don't think this should be the
case; and if it has to, it should be documented.
$ x=y
$ echo ${| declare -n REPLY=x;}
y
$ declare -p x
bash: declare: x: not found
$
inconsistent handling of closing brace inside no-fork command substitution
See:
$ ${ case } in }) echo uname; esac }
Linux
$ ${ case }x in }x) echo uname; esac }
bash: command substitution: line 25: syntax error near unexpected token `x'
bash: command substitution: line 25: `}x)'
$ ${ case }x in \}x) echo uname; esac }
Linux
$
I don't think this should be a syntax error because the closing brace
is not in a place it can terminate the command substitution.
Oğuz
Re: A feature request regarding redirection to variables
On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote:
>
> A very common thing I need to do when writing bash is to collect both
> the stdout and stderr of a command. This can be done relatively
> reasonably with files but it would be very attractive to be able to
> redirect these directly to a variable some how.
The new no-fork command substitution feature already allows this:
$ f(){ echo foo; echo bar >&2;}
$ a=${ { b=${ f;};} 2>&1;}
$ declare -p a b
declare -- a="bar"
declare -- b="foo"
You just need to wait for the next release
Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, Koichi Murase wrote: > > In that case, a question would be what would be the standard way to > specify the Bash-specific variable, > 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.
Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, jidanni wrote: > Maybe on the list of config files bash looks at, > there should be also .config/bash/... as that is > the trend these days... > Trends come and go. If there is demand for this feature bash should do it by honoring an environment variable like BASH_HOME when looking for rc files instead of exploring a fixed path. -- Oğuz
Re: Missing documentation "-bash_input"
On Wednesday, November 29, 2023, Klaus Frank wrote: > One thing though, I probably should already know that, but why is a $0 > needed even though a command was already specified? Shouldn't the command > itself be $0? No, $0 is used in error messages: $ bash -c '"' foo foo: -c: line 1: unexpected EOF while looking for matching `"' $ You wouldn't want the entire script printed for every error. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Do you mean something like a "fork_noreparent" builtin that would call > make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the > child would have to call ? > I don't have a preference for either. I oppose it being a shell option because first, it's a single function call that works on only one target platform; and second, its effect doesn't seem to stick. If I'm not missing anything, if I enable the proposed noreparent option in a shell and run a command, and that command forks, its children won't receive the death signal when the shell dies. It doesn't make any sense. Unless there is a way to make it stick and affect all descendants of the shell process, I don't think this would be very useful as a loadable builtin either. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov > 2023 16:05:38 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 Patch > Level: 21 > Release Status: release > > Description: > Hi, > > I would like to suggest a new shell option to ensure child processes are > automatically killed when the parent dies. > > Right now, it's already possible to emulate this feature by setting a trap > to kill all child processes on exit (trap "kill 0" EXIT), but obviously it > doesn't work if the process is terminated by a signal that cannot be caught > (like SIGKILL). > > On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate > the parent termination signal to the child, regardless of whether the > signal can be caught or not. > > The rationale for this feature is that scripts spawning background > processes to listen to various events (udev events, window manager events, > etc) often leave orphan processes behind when terminated forcefully. > > I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Re: Idea: jobs(1) -i to print only :%ID:s
On Thursday, November 9, 2023, Steffen Nurpmeso wrote:
>
> I mean some scripting on "jobs | wc -l" would do that, though. :(
> Maybe i should just write a function that builds the string
> necessary to do what i wanted with %* or "%1-2 %4" etc.
> Eh. Forget about it.
>
Can't you abuse jobs -x somehow? Like this perhaps
jobs -x printf '%s\n' %{1..100} | awk '!/%/{print "%"NR}'
--
Oğuz
Re: Defaults when cross-compiling
On Tuesday, November 7, 2023, Chet Ramey wrote: > > It's interesting that musl supports brk but not sbrk It doesn't support locales either. I always assumed it's someone's toy project but looks like there are Linux distros shipping it instead of glibc. Huh -- Oğuz
Re: test -lt inconsistent about white space
On Sun, Oct 29, 2023 at 8:49 AM Paul Eggert wrote: > My understanding is that Bash was intended to allow both leading and > trailing whitespace. This is compatible with ksh and with Dash. If > that's the intent, Bash should be consistent about it, just as ksh and > Dash are. There seems little point to allowing one nonempty set of > whitespace characters before the integer, and a different nonempty set > of whitespace characters afterwards. legal_number was isint, which skipped both leading and trailing space using the whitespace macro. See here: https://git.savannah.gnu.org/cgit/bash.git/tree/test.c?id=726f63884db0132f01745f1fb4465e6621088ccf#n354 I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this.
Re: test -lt inconsistent about white space
On Saturday, October 28, 2023, Paul Eggert wrote: > Bash should treat trailing whitespace the same way it treats leading > whitespace, Why? The same commands fail on bosh, yash, and zsh too. -- Oğuz
Re: BUG: Colorize background of whitespace
On Thursday, October 26, 2023, Phi Debian wrote: > On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge wrote: > > > > > Ahh. That wasn't clear to me. Thanks. > > > > > Ouch got caught the same way. This can be reduced to > > $ clear > $ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n" > $ # Recall and run prev command > repeat the later until top lines scroll out. > > I added ;4 in the first \e i.e Underline to show that doing output is > just a cursor movement (not a char painting) as would do any other cursor > positioning esc seq. > > Doing so we see that on both the color and the underline are not > decorated, on top lines, this is normal > > When the scroll out occurs, the underline is never painted, as expected, > yet the BG color of the 'tab' is decorated. > > This is because there is a bogus \n right after the SGR sequence > \e[36;44;4m\n this later \n say we open and SGR attribute, and \n will > preserve it on scroll out, BUT colors at not completly SGR as stated here > > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html search for > *"ANSI X3.64-1979"* > > > *When we remove the bogus \n all is normal* > > $ clear > $ echo "\e[36;44;4m\some colored\ttext with\ttabs\e[m\n" > > many time. > > > Generally speaking it is not good to leave an open SGR sequence before a > \n, when emitting SGR before the \n it is wise to have a closing sequence > \n[m\n > I can reproduce this behavior on all the terminals I have access to except xterm on Solaris 10, it never paints the background of a tab, which is at least consistent. I wonder what changed... -- Oğuz
Re: [PATCH] printf: add %#s alias to %b
On Wed, Sep 6, 2023 at 9:38 AM Robert Elz wrote: > Adding a different %b to printf(1) wasn't currently even proposed, just > deprecating the current one so it wouldn't conflict with the usage of > %b in printf(3) (which is being defined in C23, and is apparently already > firmly entrenched, even though C23 is not yet (quite) formally released). > > There was no proposal (yet) to provide a replacement for %b (which would > not actually be deprecated, if it were to be, for ages yet) - though the > %#s idea was proposed, and implemented in a couple of places (incl bash > I believe) - technically according to the rules, it would be too late now > to even mention that in the upcoming POSIX version, though there was some > talk of bending that rule, so a hint could be provided to applications as > to how they might move away from %b (the existing proposal is nonsense). > > My guess is that none of this will happen now, and %b, or possible alternates, > won't get any special mention in the forthcoming POSIX standard - so %b > in printf(1) would remain just like it is now for several decades at least. > (%b will appear in POSIX printf(3) in the next version after this one, > when POSIX aligns itself with C23 (or later) which contains that - C23 is > too late to be considered for the forthcoming POSIX version, and C17 does not > contain %b in its printf function). Thanks. This entire discussion is nonsense; a proposal to deprecate a useful feature appears out of the blue, patches are sent, alternatives are listed, a whole fuss is made. Yet the only argument supporting said deprecation is maintaining consistency with C23. Why is it important to do that? No answer. It's nonsense. I don't think bash should deprecate %b. If a built-in way to convert to/from bases other than 8 and 16 is desired, bash can do it like ksh does or invent a new way. But breaking backwards compatibility so that you can say "well, at least my shell is consistent with C23" would be plain idiocy. > > kre > >
Re: [PATCH] printf: add %#s alias to %b
On Tuesday, September 5, 2023, Chet Ramey wrote: > to print binary literals > What's the point? Does anyone need this feature in their shell scripts (and can't afford to use bc for it)? -- Oğuz
Re: RFC: changing printf(1) behavior on %b
On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote: > My vote is for posix_printf %B mapping to libc_printf %b In the shell we already have bc for base conversion. Does POSIX really have to support C2x %b in the first place?
Re: set -e not working as expected with conditional operators
On 6/2/23 4:01 AM, rpaufin1 wrote: However, the result should be the same. The manual says otherwise: The shell does not exit if the command that fails is [...] part of any command executed in a && or || list except the command following the final && or ||
Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context
22 Mayıs 2023 Pazartesi tarihinde Martin D Kealey yazdı: > I disagree: this would constitute a major change, breaking behaviour that > is (for good reasons) depended on. > How so? I wouldn't expect expanding `a[1]' to not fail when `a[1]' is unset and `set -u' is in effect, and can't see why anyone would either. -- Oğuz
Re: `wait -n` returns 127 when it shouldn't
On 5/17/23 3:27 PM, Martin D Kealey wrote: On Wed, 17 May 2023 at 20:20, Oğuz İsmail Uysal wrote: On 5/16/23 8:35 PM, Aleksey Covacevice wrote: [original code elided as it's been mangled by line-wrapping] This boils down to the following true & false & wait -n With respect, I disagree with that statement of equivalence. The only way for the loop to terminate is when `wait` returns 127, after both children have been reaped. By when the non-zero exit status of "false" will have been noted, and then used as the return value of the function. Must have misread then, thanks
Re: `wait -n` returns 127 when it shouldn't
On 5/16/23 8:35 PM, Aleksey Covacevice wrote:
waitjobs() { local status=0 while true; do local code=0; wait -n ||
code=$? ((code == 127)) && break ((!code)) || status=$code done return
$status } # Eventually finishes: while true; do ( true & false &
waitjobs ) && break; done
This boils down to the following
true &
false &
wait -n
There is no guarantee that `wait -n' will report the status of `true',
the shell may acquire the status of `false' first. It's not a bug.
Re: nofork command substitution
On 5/15/23 9:51 PM, Chet Ramey wrote:
Everything is shared between the comsub and its caller, with a
couple of documented exceptions. So it's just like calling `fg' in the
current execution environment, but capturing the output.
Oh, okay then. Thanks.
How about this?
$ declare -i x
$ y=${ :;}
$ declare -i z
bash: make_local_variable: no function context at current scope
$
Re: nofork command substitution
On 5/15/23 8:35 PM, Chet Ramey wrote:
Please test it out
$ cat
^Z
[1]+ Stopped cat
$ x=${ fg;}
foo
foo
<^C or ^D here>
$ declare -p x
declare -- x="cat"
$
Is this intended?
Re: Possible problem with ${var%%[...]*}
2 Nisan 2023 Pazar tarihinde Martin Schulte yazdı:
> Hello,
>
> in the following lines I consider dash's behaviour as correct an bash's as
> wrong:
>
Bash expands `<()' as a process substitution. If you escape `<' or `(' it
works fine.
I am surprised that `<()' is not a syntax error when `()' is though.
--
Oğuz
Re: IFS field splitting doesn't conform with POSIX
On 3/30/23 7:51 PM, Felipe Contreras wrote: So? This is argumentum ad populum. The fact that most shells do X doesn't imply that POSIX says X. POSIX documents existing practice. If what it says differs from what the majority of shells do, then it's POSIX that is wrong. And this mailing list is not the right place to complain about it. Yes. 'foo,bar,' has two terminators, and therefore two fields. 'foo,bar,roo' has two terminators and therefore two fields, plus garbage. You want to interpret 'foo' as a field, even though it does not have an an explicit terminator. But that's not specified anywhere in POSIX. POSIX doesn't say what should be done with the text after the last terminator. You could throw it away and still be conforming to POSIX. I don't think *to SPLIT using delimiters as field terminators* involves leaving any part out.
Re: IFS field splitting doesn't conform with POSIX
On 3/30/23 2:12 PM, Felipe Contreras wrote: IFS=, str='foo,bar,,roo,' printf '"%s"\n' $str zsh is the only shell that generates an empty last field, no other shell exhibits this behavior. Besides your link says: >The shell shall treat each character of the IFS as a delimiter and use the delimiters as *field >terminators* to split the results of parameter expansion, command substitution, and arithmetic >expansion into fields. So the delimiters terminate fields, not separate them.
Re: Bash not portable to C23
On 3/24/23 4:49 AM, Paul Eggert wrote: a strict C23 compiler Does such a compiler exist? Is C23 even published yet?
Re: Having an alias and a function with the same name leads to some sort of recursion
On 2/18/23 2:05 AM, Chet Ramey wrote: If the shell reads an unquoted word in the right position, it checks the word to see if it matches an alias name. If it matches, the shell replaces the word [in the input] with the alias value, and reads that value as if it had been read [from the input] instead of the word. This isn't what bash does. See: $ alias foo='cat
Re: "builtin jobs" does not output to stdout.
On 2/15/23 2:52 AM, Koichi Murase wrote:
two or three command substitutions are generally not considered "so
many command substitutions".
I can't reproduce a great deal of unresponsiveness with five or six
either, and my computer is very old too. I think this "delay" you
mentioned has more to do with the commands being substituted than bash.
You might hear of Fish shell is good, but which part of Fish shell is
considered good? They are just good for interactive behaviors. When we
focus on the language design, Fish shell is actually worse than Bash.
It's all about priorities; if your top priority is fashionable prompt
strings, you won't mind the inferior language.
Of course, there is no case where ${ list; } is "absolutely
necessary". But in that logic, the shell functions are not "absolutely
necessary", and even the command substitutions are not "absolutely
necessary" as everything can be in principle processed in combinations
of pipelines and { list; }, etc.
But they benefit the user tremendously.
OK, I understand what you try to say, (though I regard "no one ever"
and "any sense" as exaggerations; at least the developer who
introduced the feature should have had the reasoning and also should
have used it.
The developer doesn't count as an organic user. And ksh93 has been
around for three decades; if there were demand for the feature in
question, other shells would have copied it already.
I still think it benefits the users, even though it can be thought of
kind of syntax sugar for `list > tmp; var=$(< tmp)' (as managing the
temporary files properly is usually.non-trivial).
How many forks does that avoid anyway? Let's be realistic, the overhead
from one fork is not enough to warrant new syntax.
Re: "builtin jobs" does not output to stdout.
13 Şubat 2023 Pazartesi tarihinde Koichi Murase
yazdı:
> One of the
> cases that the fork cost of $() becomes a problem and that other
> languages cannot be really used is the prompt setting `PS1' containing
> command substitutions.
Bash has many escape sequences to enrich your prompt strings. If they don't
meet your needs and you find yourself embedding so many command
substitutions in them that there is a discernible delay, perhaps it's time
you give other shells a try. I hear fish is good.
An example is a shell function: a shell
> function can change the global variables (or previous-scope variables
> with Bash's dynamic scoping) and, at the same time, can output data to
> stdout. When one wants to capture the stdout of such a function while
> keeping the changes made to the global variables, the command
> substitution cannot be directly used.
It's not a good example because there isn't much difference between `f() {
list; }; x=$(f)' and `x=$(list)', they both read the output of `list' into
`x'. When is it absolutely necessary to both retain the side effects of
`list' and save its output to a variable?
Anyway, if there are no use cases or no benefits at all, ksh didn't
> have the feature.
>
Ksh has many features no one ever uses; some of them don't make any sense,
some don't even work. Check out <https://github.com/ksh93/ksh>, it's a mess
compared to bash.
--
Oğuz
Re: "builtin jobs" does not output to stdout.
13 Şubat 2023 Pazartesi tarihinde Koichi Murase
yazdı:
>
> Nevertheless, even if we forget about trap, jobs, etc., ${ list; }
> alone is very useful as it's free from the fork cost
Shells fork all the time. If your application can't afford the overhead,
you've chosen the wrong language to write it in.
> and also can
> affect the parent shell context when it wants to.
This doesn't sound like an upside to me, I can't think of any use case
where it wouldn't make the code more confusing.
--
Oğuz
Re: "builtin jobs" does not output to stdout.
On 2/13/23 2:43 PM, Koichi Murase wrote:
I guess just the support for ksh's ${ list; } [1] would make
everything simple and clear. One can simply call ${ jobs; }, ${ trap
-p; }, etc. without thinking about subshells.
I don't see what difference that'd make. A subshell inherits its
parent's job list, and `$(trap ...)' expands to what `trap ...' would
output if it were run in the parent shell; these are well specified in
the standard.
I think `builtin' should be fixed and the rest left alone.
Re: unset does not remove functions like a[b] unless -f is specified
4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı: > > I understand. But I think both bash and zsh should change their behavior to disallow the functions in question at least in posix mode, and the standard shouldn't allow it, that's what I'm saying -- Oğuz
Re: unset does not remove functions like a[b] unless -f is specified
On 2/4/23 12:23 PM, Koichi Murase wrote: Changing the behavior related to the function names wouldn't make the behavior of the shell entirely unspecified I see, but that's not what you're suggesting. You're suggesting that how command search and execution works be changed to allow functions that contain slashes in their names to prevent command search, and shadow filesystem entries including those of standard utilities. The fact that bash and zsh already allow it doesn't mean it's a good idea. And it's easier to make the overall behavior unspecified than examine each shell and document this new behavior; preferable too considering how little it benefits the user.
Re: unset does not remove functions like a[b] unless -f is specified
4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı: > Wouldn't it be possible to make the result of defining the function > names with slashes unspecified in a similar idea? If you mean like declaring that a shell's overall behavior be unspecified once a function with a name that wouldn't make a valid variable name defined or something like that, then yeah, I guess they could say that in the standard. But then how would you execute a program that resides in, for example, the current directory portably? `(exec ./program)`? I don't think that's a good idea. I don't have any personal reason to support or not support what you propose, but that names of functions and pathnames of executables can clash even under POSIX mode doesn't feel right. I'm not against periods and colons in function names though. -- Oğuz
Re: unset does not remove functions like a[b] unless -f is specified
4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı: > Is Bash required to strictly follow the POSIX > standard even for non-POSIX shell scripts that use Bash extensions? It promises POSIX compatibility in POSIX mode, and POSIX says >If the command name contains at least one , the shell shall execute a non-built-in utility I think he meant he'll change that for POSIX mode only though -- Oğuz
Re: Bug: Subshell won't continue after .-sourcing a file
22 Aralık 2022 Perşembe tarihinde Dan Church yazdı:
>
> Repro:
>
>sub1=$(mktemp)
>sub2=$(mktemp)
>sub3=$(mktemp)
>
>echo '( echo "1st script executing" ; . '"$sub2"' ; echo "1st script
> still executing" )' >"$sub1"
>echo 'echo "2nd script starting" && ${THIS_SH} '"$sub3" >"$sub2"
>echo 'echo "3rd script starting"' >"$sub3"
>
>. "$sub1"
>
> "1st script still executing" will never be printed.
>
Or
$ bash -c '(. <(echo ": && uname"); echo x)'
Linux
$
x is never printed. Looks like another bug caused by aggressive subshell
optimizations
--
Oğuz
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
On 10/31/22 2:20 PM, Greg Wooledge wrote:
Bash already uses the POSIX regex functions (regcomp(3) et al.) to do
[[ =~ ]] using POSIX ERE.
Yeah, and offers no more than what your libc's regex engine has. For
example, you can't tell what `[[ x =~ .{256} ]]' (or even `[[ x =~ ""
]]') would return without knowing the operating system it's run on.
extglobs aren't like that and shouldn't be either.
Re: Multiline editing breaks if the previous output doesn't end in newline
31 Ekim 2022 Pazartesi tarihinde Greg Wooledge yazdı: > > There's no 100% portable way to determine where the cursor is. Pity > Shells like zsh that show a special symbol in these cases use a hack > to do so. There's a good explanation in this answer: > > https://unix.stackexchange.com/questions/167582/why-zsh- > ends-a-line-with-a-highlighted-percent-symbol#answer-302710 > Thanks for the link. The hack is clever but the result is ugly. I'd much prefer the current behavior of bash. -- Oğuz
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
31 Ekim 2022 Pazartesi tarihinde Martin D Kealey yazdı: > > With the exception of the !(LIST) negation, there's a direct > correspondence between extglob and any other regex format. Translating > between them is trivial. > If we use the standard POSIX BRE or ERE, then there's no additional code to > ship; it's included as part of the OS. The hard part is what to do with > (!LIST), which was the point of my previous post. > That'd be clunkier than what we already have. Bash targets many platforms and it'd have to target as many regex engines if it were to translate extglobs to posix regexes. You can't expect all of them to be compatible with each other, and they are not. So, if we wish to translate extglobs to regexes and have them work regardless of the platform, the easiest way forward is to adopt a third party regex engine; about which I said enough in my previous email. The problem is that it DOESN'T work fine. In practice people encounter > abysmally slow extglob matching. > *when matching against a huge string. Which is rare in my experience, but of course should be taken into consideration if there are multiple bug reports; I didn't say anything against that. -- Oğuz
Re: Multiline editing breaks if the previous output doesn't end in newline
28 Ekim 2022 Cuma tarihinde Albert Vaca Cintora yazdı: > > Option A: If the previous command doesn't end in a newline, > add a newline manually. This is what most shells do. This sounds wrong. How are you going to know if the previous command ends in a newline or not then? > Option B: Fix the line editor to take into account when the > prompt doesn't start at column 0. > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if the cursor is not at column 0. -- Oğuz
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
On 10/30/22 3:25 PM, Martin D Kealey wrote: How much faster do you think it can be made? I don't know, irrelevant though. The problem is not that individual steps are slow, but rather that it takes at least a higher-order-polynomial number of steps, possibly more (such as exponential or factorial). Speeding up the individual steps will make no practical difference, while pin-hole optimisations may dramatically speed up some common cases, but still leave the most general cases catastrophically slow. These are technical details; no user cares about them. The purpose of my suggestions was to /minimize/ the complexity that becomes part of Bash's codebase, while leaving as few pathological cases as possible - preferably none. I meant complexity of the language, not the codebase. In my opinion "make the existing extglob code faster" is a wasted effort if it doesn't get us to "run in at-most quadratic time" and preferably "run in regular (linear) time", and so that basically amounts to "write our own regex state machine compiler and regex engine". This is a non-trivial task, and would fairly obviously add *more* complex code into Bash's codebase than any of my suggested alternatives. extglobs are already a part of the bash language. All of your suggested alternatives involve expanding the language in question. That's why I disagree with all of them. (Even my options of "postprocess the codebase" or "modify an existing regex compiler" would leave their execution components untouched; only the compilation phase would be modified, and a modified regex compiler would at least stand a chance of existing as a stand-alone library project.) If you mean bash should start shipping a huge library like pcre for solving an edge case, I don't think that's reasonable at all; why take on such a burden when you already have something that works fine in practice?
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
30 Ekim 2022 Pazar tarihinde Martin D Kealey
yazdı:
>
> So the options would seem to be:
> (a) prohibit inversions (you get to pick EITHER extglob or rexglob, not
> both);
> (b) bypass convert-to-regex when inversions are present;
> (c) use PCRE or Vim RE, which already support negations (though not in the
> same form); note that these do not have linear ("regular") time performance
> in any but the trivial cases;
> (d) compute the "inverse" regex for a given negation (this may require Vim
> RE, see below);
> (e) post-process the compiled regex (this would be highly dependent on the
> specific RE implementation);
> (f) pick an existing regex engine, and add the necessary logic to handle
> negations and conjunctions (see below);
>
Or
(g) make the existing extglob code faster and avoid introducing more
complexity into the shell.
Which, in my opinion, is the easiest and most realistic option.
--
Oğuz
Re: Function declarations produce no trace nor trigger debug trap while having side effects
28 Ekim 2022 Cuma tarihinde Erik Adelbert yazdı: > > 1 there is an error > 2 the debug TRAP is not invoked before the function definition > 3 the function definition is required to return 0 if successful > 4 the debug TRAP is invoked after the successful function definition > > This results in an effective masking of the error from the debugging > support. This sounds like a misuse of the debug trap. The error can be caught using the err trap, why don't you use that instead? -- Oğuz
Re: wait inside subshell waits for sibling
27 Ekim 2022 Perşembe tarihinde Chet Ramey yazdı: > > Yep, this is a problem. I'll have a fix in the next devel branch push. > Thanks -- Oğuz
Re: Function declarations produce no trace nor trigger debug trap while having side effects
27 Ekim 2022 Perşembe tarihinde Erik Adelbert yazdı: > Unless we have missed the related documentation, > You have. > trap [-lp] [[arg] sigspec ...] > [...] If a sigspec is DEBUG, the command > arg is executed before every simple command, for > command, case command, select command, every arithmetic > for command, and before the first command executes in a > shell function [...] -- Oğuz
Re: wait inside subshell waits for sibling
24 Ekim 2022 Pazartesi tarihinde Robert Elz yazdı: > [...] That the shell happens to > have forked other processes for its own reasons should make no > difference at all. Agreed. In the case of process substitutions it is documented that their use may change wait's behavior > If id is not > given, wait waits for all running background jobs and > the last-executed process substitution, if its process > id is the same as $!, but what the manual says is not what actually happens; in the OP $! is the PID of : & when wait is called. And it doesn't even wait for only the last-executed one, it waits for all of them: $ ( : & wait ) > >(sleep 3) > >(:) *hangs for 3 seconds* -- Oğuz
Re: wait inside subshell waits for sibling
24 Ekim 2022 Pazartesi tarihinde Emanuele Torre
yazdı:
>
> To inhibit this optimisation, you can wrap your subshell compound
> command (or simple command) in a group command, and apply the
> redirections to it instead of the subshell command:
>
> { (: & wait) ;} > >(cat)
>
> Or, in your specific case, use "$!" to only wait for the most recent
> background job.
>
> (: & wait -- "$!") > >(cat)
>
Thanks, I'm not looking for a workaround.
--
Oğuz
wait inside subshell waits for sibling
To reproduce: $ echo $BASH_VERSION 5.2.2(3)-release $ ( : & wait ) > >(cat) *hangs* It should return immediately, but hangs instead.
Re: -v no longer works for associative arrays
13 Ekim 2022 Perşembe tarihinde Chet Ramey yazdı: > > You know that referencing an array variable without a subscript is > equivalent to referencing element 0 (or "0"). > Yes, but I didn't know that it applied to test -v as well. Thanks for the reply -- Oğuz
Re: -v no longer works for associative arrays
13 Ekim 2022 Perşembe tarihinde Chet Ramey yazdı: > There are other ways to test whether or not an associative array has any > set elements, but there was no way to use `*' or `@' as a key in previous > versions. > test -v seems broken anyway $ declare -A foo=(a 42) $ declare -a bar=(42) $ test -v foo; echo $? 1 $ test -v bar; echo $? 0 -- Oğuz
Re: bash core dumps doing glob pattern on long string
9 Ekim 2022 Pazar tarihinde Phi Debian yazdı: > > $ [[ $(printf '%010d' 0) == +(0) ]] > > I see 3 way of fixing this > I'm not familiar with how extended globs are implemented in either shell but this doesn't look like something that'd involve recursion. -- Oğuz
Re: feature request: new builtin `defer`, scope delayed eval
8 Ekim 2022 Cumartesi tarihinde Cynthia Coan yazdı: > > [...] I think > use cases outside of cleanup are relatively sparse, [...] There. There already are several ways to do cleanup on exit/return using existing features, why add one more? > [...] With your syntax you still have to be aware of what's > in that trap [...] > Not really. If, for some reason, I didn't know what's in that trap and were super paranoiac about it, I could do oldaction=$(trap -P EXIT) trap 'eval "$oldaction"; bar' EXIT I've never been in such a situation though. Don't get me wrong, I just like it when new features align with the old ones and work together nicely. -- Oğuz
Re: feature request: new builtin `defer`, scope delayed eval
On 10/8/22 6:03 AM, Cynthia Coan wrote: Otherwise, I think we can perhaps reword this into two smaller features: "function local trap signals", and I don't think this would be a feature worth the time to implement and the complexity it would introduce. Is there any other use case for this than cleaning up temporary files on function return? "options to safely append/prepend to a trap" (for some definition of 'safe', perhaps this just means separating by ';'? Unsure if there's a better way off the top of my head). This can be achieved by adding a new option to `trap' that causes it to print the action string for given condition. Let this option be named `-P', the user would do something like this to update a trap: trap "foo;" EXIT trap "$(trap -P EXIT)bar;" EXIT
Re: Looking to the future (was Re: Light weight support for JSON)
On 8/29/22 5:48 AM, Martin D Kealey wrote:
The Shell persists because it has one killer feature: it does double duty
as a scripting language and as an interactive command language. But we're
kidding ourselves if we think that no other language could fill that gap:
Python has a respectable interactive mode, though its focus is on objects
rather than processes and files; the interactive "debugger" console inside
Firefox speaks Javascript; and even "perl -d" is almost usable.
So, neither of those could fill that gap. What could then?
As for the future, I believe that if we don't move towards making the POSIX
sh behaviour a truly optional part of an otherwise-more-sane language, we
condemn Bash to continued obscurity and eventual extinction.
Nah. I think Bash already has too many features over POSIX; anything
beyond indexed arrays, indirect expansions, and
`${parameter/string/replacement}' is bloat.
Besides, who is going to evolve Bash into this "more-sane language"?
Re: Revisiting Error handling (errexit)
8 Temmuz 2022 Cuma tarihinde Yair Lenga yazdı:
>
> Practical Example - real life. A job has to copy 3 critical data files. It
> then sends notification via email (non-critical).
>
> #! /bin/bash
> set -o errfail
> function copy-files {
> # ALL files are critical, script will not cont
> cp /new/file1 /production/path/
> cp /new/file2 /production/path/
> # Use the files for something - e.g., count the lines.
> important-job /production/path/file1 /production/path/file2
>
> ls -l /production/path | mail -s "all-good" not...@company.com ||
> true# Not critical
> }
>
> if copy-files ; then
> more-critical-jobs
> echo "ALL GOOD"
> else
> mail -s "PROBLEM" nor...@company.com < /dev/null
> fi
>
> What is the difference ? consider the case where /new/file1 does not
> exists, which is critical error.
> * Without errfail, an error message will be sent to script stderr, but the
> script will continue to copy the 2nd file, and to perform the
> important-job, even though the data is not ready.
How is this any better than doing `cp ... && cp ... && important-job ...'?
--
Oğuz
Re: bash 5.1 heredoc pipes problematic, shopt needed
24 Nisan 2022 Pazar tarihinde Ángel yazdı: > > I think a shopt makes more sense. Forcing heredocs to be files although > something legit to request, is more a caller workaround to bugs in > called programs. > https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00084.html -- Oğuz
Re: Bash-5.2-alpha available
22 Ocak 2022 Cumartesi tarihinde Chet Ramey yazdı: > > Because they should behave identically to other forms of quoting that bash > handles in here-documents. Why should $'' be different from '' only within > here-document bodies? Because it'd be useless otherwise. Why would anyone use $'' in a here-document other than for embedding escape sequences? -- Oğuz
Re: Bash-5.2-alpha available
22 Ocak 2022 Cumartesi tarihinde Chet Ramey yazdı: > > $'\n' is identical to > ' > ' > > Here-document bodies are parsed as if they are within double quotes, and > single quotes are not special within double quotes. > Okay, it kinda makes sense. But what is the point of allowing dollar-quotes inside here documents then? -- Oğuz
Re: Bash-5.2-alpha available
On Fri, Jan 21, 2022 at 6:28 PM Chet Ramey wrote: > a. Fixed a bug that assigned a value to the variable name supplied as an >argument to `wait -p' when there were no jobs. This doesn't seem like it's fixed $ bash -c 'echo $BASH_VERSION; unset foo; for i in 1 2 3; do wait -p foo; declare -p foo; done' 5.2.0(13)-alpha declare -- foo="0" declare -- foo="1638738736" declare -- foo="1638738960" > e. Here-document parsing now handles $'...' and $"..." quoting when reading > the >here-document body. And I don't think this is very useful with aposthropes remaining $ cat <
Re: bash dislikes empty functions or flow control bodies
18 Ocak 2022 Salı tarihinde yazdı: > [...] those situation exist and require me to catch this problem > with additional code: >a: defining an empty function will throw a syntax error >b: defining an empty bodies flow control construct will thow a syntax > error > Why make it a special case? What's wrong with prepending all of them with `:;'? -- Oğuz
Re: bash manual on interactive shell
On Mon, Dec 13, 2021 at 8:31 AM Mallika wrote: > "An interactive shell is one started without non-option arguments, unles*s* > -s is specified, without specifying the -c option, and whose input and > error output are both connected to terminals (as determined by isatty(3)), or > one started with the -i option." > > I'm a little confused about how all the and's and or's combine (I suppose > it's obvious if you're a little more familiar with the material - but it > would be great if it were possible to express this by indentation), > > but I'd actually decided to write in just to clarify that first line: > "started without non-option arguments," > > Does "option arguments" mean "option*al* arguments"? > If so, is the statement even correct? i.e. should it not be > "started without optional arguments"? It says "non-option" arguments; in other words, arguments that aren't options. > > If the double-negative* is *actually correct, wouldn't the same sentiment > be expressed by "started with only option(al?) arguments"? Double-negatives > are inherently confusing, so it would be helpful to avoid them. No. An "option argument" would be an argument that follows an option, such as `extglob' in `bash -O extglob'. That sentence is not about them. As to what non-option arguments are, all arguments in `bash file command_name positional_parameters' are non-option arguments, so are command name and positional parameters in `bash -s command_name positional_parameters'; but the former starts a non-interactive shell, and the latter starts an interactive shell since `-s' is specified. > > -Mallika
`${array[index]=value}' broken in devel
To reproduce:
$ a=()
$ echo ${a[42]=foo}
Desktop Documents Downloads mpv-shot0001.jpg Music Pictures Public
Videos VirtualBox VMs
$ declare -p a
declare -a a=([42]="foo")
or
$ declare -A a
$ echo ${a[foo]=bar}
P�ϝU
$ declare -p a
declare -A a=([foo]="bar" )
Oğuz
Re: bash conditional expressions
> I agree that the `mtime >= atime' behavior should be restored; ``file > is newly created or was accessed since last modified'' is not a useful > information, nor is the opposite. Or, -N can be split into -A (atime > mtime) and -M (mtime > atime), and everyone would be happy :D
Re: bash conditional expressions
On Fri, Nov 12, 2021 at 12:44 PM Mischa Baars wrote: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; This seems to have changed as a result of this bug report: https://lists.gnu.org/archive/html/bug-bash/2019-07/msg00022.html > > This means that newly created object files are no longer recognized by the > compile scripts as new object files and executables are no longer linked > against these new object files. > > Could you please restore the Fedora 32 behaviour? Someone must have read > the bash manual a little too precise, because now the statement only > returns true when a 'touch -a test' is given and not when a 'touch -am > test' is given. I agree that the `mtime >= atime' behavior should be restored; ``file is newly created or was accessed since last modified'' is not a useful information, nor is the opposite.
Re: hash not restored after running command -p
On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote: > Temporarily using a default value of PATH is akin to modifying it. But they are not the same thing, and you know this. The standard is neither on your side nor mine.
Re: hash not restored after running command -p
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 searched for at all. > It should not be found, even if it is remembered. Is the rest of this paragraph your opinion too or did I miss where the standard/bash manual says anything to this effect? > > The way it works now, is that the hashed keys are made into aliases. > These hash-aliases circumvent PATH search. > It is not specified by POSIX and I think it is an unwanted trap. POSIX does not mandate that the directory portion of the pathname used for executing a command be found in the current value of `PATH' either. Perhaps this calls for an clarification request. > Implicitly this sets PATH. > So it should not mess with the outcome of later PATH searches. Again, nowhere it is said that `command -p' involves modifying `PATH'.
Re: hash not restored after running command -p
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 for the utility again unless the PATH variable has been the subject of an assignment'' pretty much covers it. `command -p command_name' doesn't alter `PATH', and the shell may or may not remember the location of `command_name' obtained using the default value for `PATH'. > Note that it is not always the same person writing the code. > The script might be written/changed by someone unaware of the side effects. > I assume script writers would know about PATH and alias effects, > less so about 'hash' and even fewer people would know about 'command -p'. Yeah, it'd be better if the feature in question were documented.
Re: hash not restored after running command -p
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 the hash as alias for commands, that are not in your PATH, > > > seems risky though. > > > > Why? Risky how? > > Risky, mostly on a cognitive level. > > 'command -p foo' doesn't look like it has a side effect. How does a command look like it has side effects? > > E.g. assume you have /usr/local/bin/foo and /bin/foo > PATH=/usr/local/bin > command -p foo > foo > > You would not think that /bin/foo is executed for foo, given the value of > PATH. I suppose I would not, because the manual doesn't say `command -p' has this effect. I'll give you that. > > It could also lead to bugs. > E.g. > PATH=/usr/local/bin > source script > foo > > When the 'command -p foo' is introduced in the sourced script, foo changes. Yes, that's how `source' works; contents of the sourced file alters the sourcing application's execution environment. In addition to calling `command -p foo', if the sourced file changes `PATH', or defines a function named `foo', or enables `expand_aliases' and defines an alias named `foo', `foo' 'changes'. > > -- > Regards, Mike Jonkmans >
Re: hash not restored after running command -p
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? -- Oğuz
Re: hash not restored after running command -p
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 the behaviour is a bug, or at least unwanted behaviour. I'd say it's a feature, and a good one too. Not having to prefix each invocation of a utility with `command -p ' is a convenience if there's a lot of them. > > I could not find this in POSIX nor in the bash manual, but it seems true: > Assignment to PATH clears the hash table. > (Even when the value stays the same). It's in XCU 2.9.1.4: > Once a utility has been searched for and found (either as a result of this > specific search or as part of an unspecified shell start-up activity), an > implementation may remember its location and need not search for the > utility again unless the PA TH variable has been the subject of an assignment. > If the remembered location fails for a subsequent invocation, the shell shall > repeat the search to find the new location for the utility, if any.
