Re: bash 5.1 heredoc pipes problematic, shopt needed
On Mon, May 2, 2022 at 9:53 AM Chet Ramey wrote: > My preference is a portable memfd_create(); I think I could get around > its limitations. I'm sure you can google with the best of them, but I did come across this project which did some work trying to create a portable version of memfd_create(), https://github.com/lassik/shm_open_anon
Re: Building loadable builtin
On Thu, Apr 14, 2022 at 11:52 AM Robert E. Griffith wrote: > Question 3: what is the best practice for maintaining loadable builtins? > Can anyone suggest an existing loadable builtin project that I could > model mine after? I don't have too much advice on best practices, but I did write a blog post on writing builtins, along with some sample code, which you may find helpful. post: https://mbuki-mvuki.org/posts/2021-07-12-writing-a-bash-builtin-in-c-to-parse-ini-configs/ code: https://github.com/lollipopman/bash-ini-builtin-blog-post
Re: "trap" output from "if" statement redirected wrongly
On Wed, Apr 13, 2022 at 7:59 AM Frank Heckenbach
wrote:
> This script writes "foo" to bar rather than stdout as I'd expect.
>
> It's triggered by the "if" statement (which doesn't even cause
> running in a subshell, so it's not that).
>
> #!/bin/bash
> set -e
> trap 'echo foo' 0
> #false > bar # "foo" written to stdout correctly
> if true; then false; else false; fi > bar # "foo" written to bar
I don't believe this is a bug, though Chet is welcome to chime in
with an authoritative answer. The script exits after the else clause
because false returns 1 and errexit is set. At this point in the program
stdout has been redirect to the file bar, so when the trap echos to
stdout its content goes to bar as well. I don't see anything in the
docs about traps resetting their output file descriptors before they
are ran. To work around this you need to save the original stdout file
descriptor. Something like this:
#!/bin/bash
exec {STDOUT}>&1
exec {STDERR}>&2
set -e
trap 'echo foo >&${STDOUT}' EXIT
if true; then false; else false; fi >bar
Re: Squiggly heredoc - new feature request
On Tue, Aug 31, 2021 at 2:24 AM Přemysl Šťastný wrote: > > Thanks for advice. How do you use it in more detail please? You can feed shfmt an individual file to format, it defaults to using tabs for indentation: $ shfmt ~/test.sh #!/bin/bash cat <<-EOF hello! EOF Or you can instruct your editor to run shfmt everytime you save. For example I use Vim with the github.com/dense-analysis/ale plugin configured to run shfmt every time I save.
Re: Squiggly heredoc - new feature request
> Will ksh93 version ever get to upstream? This ugly 'bug' is here for > decades and really irritates me and many people, who ever used shell for > larger scripting and don't like to use tabs. I used to always prefer spaces, until I switched to auto formatting all my Bash scripts with shfmt[1]. It allows me to have indented heredocs and not worry about manual formatting. [1]: https://github.com/mvdan/sh
Re: Prefer non-gender specific pronouns
On Sun, Jun 6, 2021 at 10:28 AM Greg Wooledge wrote: > Out of these 5 choices, the one that seems to suck the *least*, according > to observed usage patterns in current written and spoken English, is > "they". I agree with Greg, *they* has become the dominant gender neutral pronoun in English. I prefer *they* over his/her as the latter is difficult to parse and makes for awkward reading. Also, as Greg mentions, there is historical precedent for the singular form of *they*.[1] [1]: https://en.wikipedia.org/wiki/Singular_they
Re: zsh style associative array assignment bug
On Mon, Mar 29, 2021 at 4:18 PM Chet Ramey wrote: > If you look at > > a=( k1 v1 k2 v2 k3 v3) > > as more or less syntactic sugar for > > a=( [k1]=v1 [k2]=v2 [k3]=v3 ) > > it's reasonable that > > a=( k1 v1 k2 ) > > is equivalent to > > a=( [k1]=v1 [k2]= ). And that's what bash does. This equivalence, though it is reasonable, creates a special case for the last value in an array which imposes a greater cognitive burden on the programmer. The programmer needs to be aware that omitting the last value will create an empty value rather than emitting an error. Given that you need quotes to create an empty value for any other element but the last: $ a=( k1 "" k2 v2 k3) $ declare -p a declare -A a=([k1]="" [k2]="v2" [k3]="" ) I would prefer the consistency and readability of always requiring an even number of arguments: $ a=( k1 "" k2 v2 k3 "") $ declare -p a declare -A a=([k1]="" [k2]="v2" [k3]="" ) In general I find that fewer surprises in a language lead to easier to grok code.
Re: Changing the way bash expands associative array subscripts
I would welcome this change, I struggled today with trying to increment an associative array in an arithmetic context. I think this change would make for much better ergonomics when working with associative arrays. Yours kindly, Jesse Hathaway
Re: Feature Request: Python-like string split and join
On Sat, Jan 23, 2021 at 11:17 PM William Park wrote: > I'm running out of special characters, and I don't want another operator > or syntax that I can't remember 2 weeks from now. :-) That's my main > issue with Zsh. I concur, I find the expansion operators devilishly hard to remember!
Re: Bash-5.1-beta available
On Fri, Sep 11, 2020 at 5:40 AM Andreas Schwab wrote: > The reason for using a process substitution is so that the loop can set > shell variables. Would using lastpipe be an option instead? lastpipe If set, and job control is not active, the shell runs the last command of a pipeline not executed in the back‐ ground in the current shell environment.
Re: Procsub.tests on OSes using named pipes
> An easy way to reproduce it is to launch a script with: " moo() { echo
> "ok";}; moo >(true)", you'll see an "ok" in your bash terminal and a
> subprocess will be blocked in an open syscall. The fact that we are seeing
> this "ok" means that the output of the parent process was never redirected to
> the child. Am I right ?
did you mean, `moo() { echo "ok";}; moo > >(true)`?
