On Tue, Feb 23, 2021 at 12:17:10PM +0100, Alex fxmbsw7 Ratchev wrote:
> what, sorry, mailing stuff isnt much clear to me, ... its not possible to
> have a var=\'\] ; assoc[$var] ?
It should work for simple assignment and retrieval.
You need to add quotes for [[ -v 'assoc[$var]' ]] to work, and ma
On Tue, Feb 23, 2021 at 02:03:30PM +0100, Léa Gris wrote:
> (
> LANG=C
> unset var assoc
> var=\'\]
> declare -Ai assoc
> assoc[$var]=1
> assoc[$var]+=1
> ((assoc['$var']++))
> typeset -p assoc
> )
This "works" in bash 5.0 but not in Debian's bash 5.1. The -i flag is
irrelevant as
On Tue, Feb 23, 2021 at 02:03:55PM +0100, Andreas Schwab wrote:
> On Feb 23 2021, Greg Wooledge wrote:
>
> > No amount of quoting will make (( 'assoc[$var]'++ )) work.
>
> (( assoc[var]++ ))
>
> Andreas.
This is not the same as assoc[$var]. Yours uses the
Oğuz (oguzismailuy...@gmail.com) wrote:
> `(( assoc[\$var]++ ))' works fine as usual.
unicorn:~$ bash-5.1
unicorn:~$ declare -A hash
unicorn:~$ key=\'\]
unicorn:~$ hash[$key]=17
unicorn:~$ (( hash[\$key]++ ))
unicorn:~$ declare -p hash
declare -A hash=(["']"]="18" )
unicorn:~$ (( 'hash[$key]'++ ))
Mike Jonkmans (bash...@jonkmans.nl) wrote:
> What does not work:
> function x ( : )
The parser is looking for () after the function name. Most likely, the
opening ( is confusing it.
unicorn:~$ bash
unicorn:~$ x() ( : )
unicorn:~$ function y() ( : )
unicorn:~$ type x
x is a function
x ()
{
felix (fe...@f-hauri.ch) wrote:
> There it is:
>
> $ declare -A map; key='foo$(uname >/dev/tty)bar'; map[$key]=
> $ echo map["$key"]
> map[foo$(uname >/dev/tty)bar]
> $ echo ${map["$key"]}
>
> $ unset map["$key"]
> Linux
Yeah, it's sad but true. I've just added a whole (short) section on
assoc
Alex fxmbsw7 Ratchev (fxmb...@gmail.com) wrote:
> bash-5.1# cat int.fail
> int() {
> declare -a int
You've declared a local array named "int" which has nothing in it.
This is inside a function named "int".
> declare i=-1 now
>
> while [[ -v int[++i] ]] && now=${int[i]} ; do
> printf %s\\n
On Thu, Mar 11, 2021 at 08:06:55AM -0700, Jason A. Donenfeld wrote:
> This behavior is quite surprising:
>
> $ declare -A blah
> $ blah['$(DOESNOTEXIST)']=broken
> $ for i in "${!blah[@]}"; do echo "$i"; done
> $(DOESNOTEXIST)
> $ for i in "${!blah[@]}"; do unset blah["$i"]; done
> bash: DOESNOTEX
On Thu, Mar 11, 2021 at 09:38:37AM -0700, Jason A. Donenfeld wrote:
> Single quotes with the nested double quote? That's nuts. But okay. I
> guess there really is some double expansion eval-like logic happening
> with the unset operator.
I removed the double quotes, as they serve no purpose there.
On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote:
> it doesnt make me much sense that unset -v assoc[$key] gives syntax error
> or so..
Think of it this way: what would happen if you had a filename in a
variable -- say, $file -- and you ran this command:
rm -f $file
You'd exp
On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote:
> no idea about your internal rules of keyword and builtin
unicorn:~$ type [
[ is a shell builtin
unicorn:~$ type [[
[[ is a shell keyword
You know how you're allowed to omit quotes inside [[ but not inside [ ?
That's because [
On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote:
> | Operating system is BionicPup64 8.0.
>
> That might. More importantly is probably whatever package management
> system it uses. I have no idea what the "ash" the bug report refers to
> is (there is an ancient shell of that name,
On Wed, Mar 17, 2021 at 01:55:56PM -0400, Eli Schwartz wrote:
> On 3/17/21 12:43 PM, Alex fxmbsw7 Ratchev wrote:
> > it makes the output no more possible if interpreted by tty
> > the \e's get processed by terminal and no more .. just an example where it
> > is so:
> >
> > var=$'1\e[G\e[K2' ; decl
On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote:
> On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote:
>
> > I thought, for a moment, that bash already used $'...' quoting for
> > newlines, but it turns out that's false. At least for declare -
On Wed, Mar 17, 2021 at 09:11:48PM -0400, Dale R. Worley wrote:
> I have it encoded in my head that $ inside "..." is respected. Subtly,
> the $'...' construction is not respected inside "...".
Bash has 5 types of quoting: '...', "...", $'...', $"..." and backslash.
$'...' is a form of quoting,
On Thu, Mar 18, 2021 at 02:01:12PM +0100, Alex fxmbsw7 Ratchev wrote:
> there is way to crop data to wanted, by cropping the exclulsions away
> but what about a way to extract data, eg @( .. ) match
> not about using [[ =~ but only var internal stuff
> .. or do i miss there something
This is reall
On Thu, Mar 18, 2021 at 02:15:19PM +0100, Alex fxmbsw7 Ratchev wrote:
> pseudo exmaple
Why not give a REAL example?
> declare -A big=( mess of data )
> var=$( declare -p big )
>
> now to extract the elements, beware with mess of data i dont mean 'mess'
> 'of' 'data'
You don't write bash code to
On Thu, Mar 18, 2021 at 02:44:06PM +0100, Alex fxmbsw7 Ratchev wrote:
> isnt it obvious ..
No.
> ${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
> and an extension for regex there
That's a feature request. Chet can discuss that with you.
All I can tell you is that this feature is not in an
On Fri, Mar 19, 2021 at 09:10:06PM -0400, Dale R. Worley wrote:
> Alex fxmbsw7 Ratchev writes:
> > yea well it does wonders, however was looking for a way without spawning
> > externals like gawk.. maybe in future there will be =)
>
> Traditionally, shell scripts depended on external binaries to
On Mon, Mar 22, 2021 at 03:12:25AM +0100, Alex fxmbsw7 Ratchev wrote:
> i realize its somewhat of a big limitation, to have only global and
> one level further ( local ) args, no per function
One or more of your assumptions are wrong.
Bash uses "dynamic scope" when it expands variables. This mea
On Mon, Mar 22, 2021 at 09:50:06AM +, Budi wrote:
> in a function k() in ~/.bashrc
>
> k(){ unset u;h=0; o=(${h:+ ! -path "./*.txt"}) ;u=($u "${o[@]}"); c=(.
> -regextype posix-extended "${b[@]}" -print); find "${c[@]}"
> }
>
> in output set -x:
>
> + unset u
> + h-0
This is clearly a fal
On Sun, Mar 28, 2021 at 10:01:14PM +0300, Oğuz wrote:
> On Sun, Mar 28, 2021 at 9:02 PM Eric Cook wrote:
>
> > in typeset -A ary=([key]=) an explicit empty string is the value
>
> No. An "explicit" empty string would be '', "", or something like that.
> After `=' a value is expected but it's not
On Mon, Mar 29, 2021 at 01:42:10PM +0100, Chris Elvidge wrote:
> On 29/03/2021 12:04 pm, ილია ჩაჩანიძე wrote:
> > How can I set default PS1 variable from source code?
> > E.g I want it to display:
> > My-linux-distro $
> > And not:
> > Bash-5.1 $
> >
>
> Set it in $HOME/.bashrc
Given that the go
On Mon, Mar 29, 2021 at 01:49:41PM -0700, L A Walsh wrote:
> Or, what do you mean by 'default'? Is it sufficient
> to set it in the system /etc/profile so it is the default
> for all users when logging in?
Sadly, that won't work. There are plenty of *extremely* common paths
from power-on to shel
On Mon, Mar 29, 2021 at 07:25:53PM -0700, L A Walsh wrote:
> On 2021/03/29 14:39, Greg Wooledge wrote:
> > On Mon, Mar 29, 2021 at 01:49:41PM -0700, L A Walsh wrote:
> > > Or, what do you mean by 'default'? Is it sufficient
> > > to set it in the system /etc/p
On Tue, Mar 30, 2021 at 12:42:46PM -0400, Eric Cook wrote:
> typeset -A tags=(); set --
> while IFS='|' read -ra ary; do
> set -- "$@" "${ary[@]}"
> done < <(
> exiftool -j *.flac |
> jq -r '.[]| {Artist, Track, Genre, Title}|to_entries[]| .key + "|" + .value'
> )
> eval 'tags=('"${*@Q}"\)
>
On Tue, Mar 30, 2021 at 09:54:35AM -0700, L A Walsh wrote:
> On 2021/03/29 20:04, Greg Wooledge wrote:
> > On Mon, Mar 29, 2021 at 07:25:53PM -0700, L A Walsh wrote:
> > >
> > >I have both /etc/profile and /etc/bashrc call my configuration
> > > scripts
On Wed, Mar 31, 2021 at 02:31:46AM +0700, by.sm--- via Bug reports for the GNU
Bourne Again SHell wrote:
> poc=whoami
> $poc
> python3 -c "print('!!')"
>
> That return 'whoami' command.
You're running into the csh-style history expansion. A lot of us simply
disable it, because it's not worth t
On Wed, Mar 31, 2021 at 09:40:34AM +0200, felix wrote:
> As bash read loop could be something slow, I use (when I'm quiet about data
> origin) something like:
>
> declare -A tags="($(
> sed -e 's/^\([^|]*\)|\?\(.*\)/[\1]="\2"/' < <(
> exiftool ...)) )"
> I'm not absolutely sure
On Thu, Apr 01, 2021 at 01:36:59AM -0700, greyw...@starwolf.com wrote:
> The following is valid shell code:
>
> d=($(ls /usr/src/pkg/*/$1));
Syntactically valid, but semantically wrong.
If $1 is not a directory, then you want:
d=(/usr/src/pkg/*/"$1")
If $1 is supposed to be a direc
On Thu, Apr 01, 2021 at 11:58:13PM +0700, Robert Elz wrote:
>
> | If $1 is not a directory, then you want:
>
> It is a directory, or I'd guess, quite likely a pattern chosen
It's amazing how many people manage to post their code with NO comments
or explanations of what it's supposed to do, wha
On Thu, Apr 01, 2021 at 02:54:55PM -0700, Greywolf wrote:
> the requirement
> to have ${var[ix]} instead of honouring $var[ix] with regard to arrays
> is another one).
Before the introduction of arrays, $var[ix] already had a meaning:
the value of the "var" parameter, followed by the 4-character s
On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote:
> But, maybe we can introduce a special syntactic treatment of `unset'
When I made a comment about the possibility of unset becoming a keyword,
Chet said he had no plans to do that.
... here:
https://lists.gnu.org/archive/html/bug-bas
On Tue, Apr 06, 2021 at 11:28:13PM +0900, Koichi Murase wrote:
> 2) we
> can distinguish the erasure of the element associated with key=@
> `unset -v a[$key]' from the entire array erasure `unset -v a[@]'.
As a counter-proposal, Chet could entirely remove the special meaning
of unset 'a[@]' and in
On Tue, Apr 06, 2021 at 06:34:21PM +0300, Ilkka Virta wrote:
> $ declare -A a=([foo]=123 [bar]=456)
> $ unset 'a[@]'
> $ declare -p a
> bash: declare: a: not found
>
> i.e. both remove the whole array, not just the contents.
Huh, so it does. I didn't know that.
In that case, I have no qualms a
On Wed, Apr 07, 2021 at 01:46:27AM +0900, Koichi Murase wrote:
> I remember there was some discussion in the bug-bash list on the
> behavior of `test -v a[@]' which actually tests whether the array `a'
> has at least one element.
> It cannot be replaced by `test -v a' because
> `a' implies `a[0]'
On Wed, Apr 07, 2021 at 03:53:43AM +0800, konsolebox wrote:
> Also if Bash could just store associative array
> values as a list to preserve store order and stop expanding
> "${array[@]}" based on the sorted order of the keys, then the slice
> function can also be applied there.
There is no sortin
On Tue, Apr 06, 2021 at 03:24:54PM -0500, Dennis Williamson wrote:
> Python 3.7 has insertion-order dictionaries. So these are dependable
> gerbils.
That explains my test results, which I didn't post. I had been told
in the past that python's dictionaries did NOT remember insertion
order, but I'm
On Thu, Apr 08, 2021 at 03:37:33PM -0400, Chet Ramey wrote:
> On 4/6/21 1:42 PM, Greg Wooledge wrote:
> > That said, the fact that you can put 'a[@]' in an indirect variable and
> > get an array expansion out of "${!x}" is completely repulsive to me.
>
>
On Fri, Apr 09, 2021 at 08:17:52AM +0800, konsolebox wrote:
> On Fri, Apr 9, 2021 at 4:08 AM Greg Wooledge wrote:
> > But apparently someone stumbled upon this trick, and passed it around,
> > and now there's a whole subculture of people who use this as a hack for
>
On Fri, Apr 09, 2021 at 03:08:25PM -0400, Craig Andrews wrote:
> Description:
> With "set -u", invoking "which" results in the output of:
> environment: line 1: _declare: unboundvariable
> That should not happen, and does not happen, with prior versions of
> bash.
> I'm usin
On Sun, Apr 18, 2021 at 04:12:10PM -0700, Ananth Chellappa wrote:
> Sincerely appreciate your time. Far as I understand, there is no
> way to accomplish what I want - concisely : *get a true private mode* (no
> logging to HISTFILE *OR* recall with history command after exiting
> private-mo
On Mon, Apr 19, 2021 at 01:16:48AM -0400, Grisha Levit wrote:
> I think you can do something similar to the patch directly in the shell by
> temporarily unsetting HISTFILE and then deleting history entries in a
> certain range and restoring HISTFILE when you are ready
I still think my solution fit
On Mon, Apr 19, 2021 at 08:28:54PM +0800, 積丹尼 Dan Jacobson wrote:
> $ e哈=1
> bash: e哈=1: command not found
> OK, but on man bash is it ever mentioned that a variable name must be all
> ASCII?
>
> ENVIRONMENT
>When a program is invoked it is given an array of strings called the
>
On Tue, Apr 20, 2021 at 11:07:51PM +0800, 積丹尼 Dan Jacobson wrote:
> Please document on the man page somewhere that set -v, +v inside case
> statements is special:
> $ cat A
> case x in x)
> set -v
> : B
> case y in y)
> set -v
>
On Tue, Apr 20, 2021 at 09:25:04PM -0400, Dmitry Goncharov via Bug reports for
the GNU Bourne Again SHell wrote:
> On Tue, Apr 20, 2021 at 2:37 PM Greg Wooledge wrote:
>
> > With case, or any other compound command, the entire compound command is
> > read from the script and p
On Wed, Apr 28, 2021 at 11:02:31PM +, Tom (AST) Watson via Bug reports for
the GNU Bourne Again SHell wrote:
> Hi...
>
> [user@box3 ~]$ echo $l
> 10
> [user@box3 ~]$ echo {1..${l}}
> {1..10}
https://mywiki.wooledge.org/BashPitfalls#pf33
On Thu, Apr 29, 2021 at 03:12:09PM +0300, Ilkka Virta wrote:
> BTW, was there some background to why they're ordered like this? I'm not
> sure if I have heard the story, and didn't see anything about it in Greg's
> wiki or bash-hackers.org (of course they tell the "what", but not the
> "why"). I di
On Thu, Apr 29, 2021 at 07:39:37PM -0700, L A Walsh wrote:
>It doesn't always do it correctly because it doesn't always know
> where it is in a line. As such it has a bug that would be fixed by
> having it really know where it was at (from talking with libcurses)
> as well as what the tabstops
On Thu, May 06, 2021 at 10:42:36AM +0300, Oğuz wrote:
> 6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> yazdı:
> >
> > But why is $# decremented after the first unset?
>
> Because `x[0]' existed then, and the number of x's members changed with its
> removal. `${
On Mon, May 10, 2021 at 09:12:33PM +1000, AlvinSeville7cf wrote:
>x=test
>case $x in
>"test") echo Y
>esac
>
>Pattern is quoted but no quote removal is performed according to docs.
Quote removal is essential, because of the way the empty string
is matched:
case $foo in
On Mon, May 17, 2021 at 04:00:10PM -0700, Carl Thompson wrote:
> Nevermind! I was misunderstanding what the 'command' builtin does!
For the archives: 'command' only suppresses functions. It doesn't
suppress shell builtins.
The typical use is when writing a wrapper function with the same name
as
On Thu, May 20, 2021 at 04:43:49PM +, Michael Jensen wrote:
> Repeat-By:
>
> echo "xxaxxon" > test.txt
> echo "@zorg" >> test.txt
> echo "@jupiterlander" >> test.txt
> cat test.txt | sort
>
> Note it prints out:
>
> @jupiterlander
> xxa
On Thu, May 27, 2021 at 05:46:41PM +0200, Alex fxmbsw7 Ratchev wrote:
> why doesnt it accept ! after |
Because ! negates a pipeline, not a simple command inside a pipeline.
On Wed, Jun 02, 2021 at 03:54:34PM -0600, v...@it4us.top wrote:
> --first script where declare -x -g works
> bar(){
>
> [[ $cnt == 1 ]] && declare -g -x nestedbug="not a nested variable-bug
> !!"
> }
>
> foo(){
> [[ $cnt == 1 ]] && bar && echo ${nestedbug:?"va
On Sun, Jun 06, 2021 at 05:12:21PM +0300, Oğuz wrote:
> If that really is a problem that has to be addressed and not
> bike-shedding, let's compromise and say "his/her" instead of "his" or
> "their".
*sigh*
I probably shouldn't do this, but let's dive into this just a bit, because
apparently it's
On Sun, Jun 20, 2021 at 07:51:03PM +0300, Teemu Leisti wrote:
> Repeat-By:
> 1. Open Bash, and command: abcdef
> 2. Click Ctrl-R, and type: bcde
> Expected behavior: The command "abcdef" is shown on the command line,
> and "bcde" is highlighted.
> Observed behavior: The command "abcdef" is shown on
On Tue, Jun 22, 2021 at 02:42:40AM -0700, Martin Jambon wrote:
> I ran into something that looks like a bug to me, although I'm not super
> familiar curly-brace command groups.
>
> Bash version: latest from GitHub mirror (commit ce23728: Bash-5.1 patch 7)
>
> Minimal repro:
>
> $ sleep 1 & { w
On Tue, Jun 22, 2021 at 01:12:10PM -0700, Martin Jambon wrote:
> On 6/22/21 4:31 AM, Greg Wooledge wrote:
> > A pipeline creates two or more subshells, one for each command in the
> > pipeline. Therefore, your wait command is running in a different
> > process than the one wh
On Tue, Jun 22, 2021 at 06:54:18PM -0700, Martin Jambon wrote:
> This is confirmed by this definition from posix:
>
> A subshell environment shall be created as a duplicate of the shell
> environment, except [...]
> In the posix definition, a subshell
> - is not necessarily implemented as a separ
On Wed, Jun 23, 2021 at 03:17:48PM -0700, Martin Jambon wrote:
> > What is the magic quality that imparts shellness?
>
> '$$' matching the process ID.
That just signifies that you're in the original shell, or the main shell,
or the root shell, or the fundamental shell, or make up whatever term
yo
On Thu, Jun 24, 2021 at 05:52:47PM +1000, Alvin Seville wrote:
> Hello! I want to understand why the following code doesn't produce any
> error:
> set -- "a b" "c"
> a="$@"
It doesn't produce an error because the designers of the shell tried
to make it "user-friendly" by having it guess what you
On Thu, Jun 24, 2021 at 09:48:59AM +0200, Phi Debian wrote:
> $ function echo { \echo the function version; \echo "$@"; }
For the record, this isn't how you write a function that wraps a builtin.
Use the "builtin" command instead.
echo() {
printf 'echo() wrapper invoked.\n'
builtin echo "$@"
On Fri, Jun 25, 2021 at 01:47:01AM +0200, Nora Platiel wrote:
> To me, "$@" expanding to multiple words would mean that:
>
> $ var="$@" foo
>
> for $# > 0, behaves the same as:
>
> $ var="$1" "${@:2}" foo
>
> which is obviously not the case.
"$@" expands like "$1 "$2" ... when used in most con
On Fri, Jun 25, 2021 at 03:15:25PM +0200, Nora Platiel wrote:
> But at least it is documented, and that part of the doc is clear to me.
> The part of the doc that I'm complaining about is this one:
>
> | A variable may be assigned to by a statement of the form
> | name=[value]
> | [...]
> | Wo
On Sun, Jun 27, 2021 at 12:19:00PM +, cheng wensui wrote:
> bash 5.1.4(1)-release (x86_64-pc-linux-gnu)
>
> when ps1 is too long ,The cursor moves abnormally ,Entering letters too
> many too long is also abnormal
>
> example :
> PS1='\033[5;37m[\033[0m\u\033[1;35m@\033[0m\033[4m\H\033[
On Tue, Jun 29, 2021 at 01:21:44PM -0700, L A Walsh wrote:
> I hope a basic question isn't too offtopic.
More of a help-bash question, in my opinion, but close enough.
> Say I have some number of jobs running:
>
> > jobs|wc -l
> 3
OK.
> Would like to pass a varname to njobs to store the answe
On Tue, Jun 29, 2021 at 09:47:30PM +0100, Kerin Millar wrote:
> On Tue, 29 Jun 2021 16:35:28 -0400
> Greg Wooledge wrote:
>
> > unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
> > unicorn:~$ njobs walsh
> > unicorn:~$ echo "$walsh"
On Tue, Jun 29, 2021 at 02:05:46PM -0700, L A Walsh wrote:
>That would be 'me', so I'm going to rule out malicious
> code injection! :-), but that's also why I used printf to
> write the output, the worst that could happen is some varname
> is overwritten with the answer, no?
Sadly, this is no
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>
> Using that with your input:
>
> njobs 'x[0$(date >&2)]'
>
> bash: printf: `x[0$(date': not a valid identifier
This is because you didn't quote "$1". Since you only ever test
On Tue, Jun 29, 2021 at 04:29:05PM -0700, L A Walsh wrote:
> > > njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>Which is detected as "illegal input" and disallowed. If you don't enable
> some security errors, they can't be as easily introduced.
Are you *still* insisting that your f
On Tue, Jun 29, 2021 at 10:11:31PM -0400, Eli Schwartz wrote:
> On 6/29/21 7:29 PM, L A Walsh wrote:
> >>> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
> It also rejects this perfectly reasonable code, which I arbitrarily
> decided not to support because if you want this you're weird:
>
On Thu, Jul 01, 2021 at 02:12:10AM -0700, L A Walsh wrote:
> What are you talking about?
>
> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>
> I don't see any arrays, let alone indexed.
The arrays were in the calls. We demonstrated a few cases already.
Since you clearly weren't p
On Fri, Jul 02, 2021 at 09:09:34AM +0200, Phi Debian wrote:
> PW$ function njobs
> > { [ "$1" != "n" ] && typeset -n n="$1"
> >typeset -a t ; readarray t <<<"$(jobs)" ;n=${#t[@]}
> > }
<<<$() is a poor imitation of < <() which is what you really want.
readarray -t t < <(jobs); n=${#t[@]}
Com
On Fri, Jul 02, 2021 at 05:45:23PM +0200, Phi Debian wrote:
> Regarding the code injection I am not sure I got it.
>
> If you are sitting at a prompt, why would you trick
>
> unicorn:~$ njobs_ref 'x[0$(date>&2)]'
>
> when you could simply type
> unicorn:~$ date
>
> I assume protected script/sou
On Wed, Jul 07, 2021 at 11:50:01PM +0200, lisa-as...@perso.be wrote:
> Have noticed that parameter expansion with `:` does not work
>
> : ${fltype:-"texi,org"} # alternative to `fltype=`
What did it do? What did you *expect* it to do?
This looks like it's related to your ongoing project to mak
On Thu, Jul 08, 2021 at 12:10:27AM +0200, lisa-as...@perso.be wrote:
> The line
> : ${fltype:-"texi,org"}
> should be an alternative to
> fltype=${fltype:-"texi,org"}
As Chet guessed earlier, you probably meant := instead of :- .
I started typing something to that effect in my first respons
On Thu, Jul 08, 2021 at 12:37:07AM +0200, lisa-as...@perso.be wrote:
> >From: Dennis Williamson
> >$ : ${foo:-bar}
> >$ : ${foo:=bar}
> >The first form is a substitution and the second form is an assignment.
> So you used `:` at the beginning and it worked?
Are you incapable of seeing the diffe
On Thu, Jul 08, 2021 at 12:33:04AM +0200, lisa-as...@perso.be wrote:
> Talking about neater design choices, you seem to imply you have some other
> way to take user options that are composed of lists, so that one does not use
> a delimited string. What is it?
I wrote a detailed message containing
> > fdir=${fdir:=$PWD}
>
> Ack!
I know. I simply gave up. At least this will "work", even if it's
completely silly.
On Thu, Jul 08, 2021 at 04:38:25AM +0200, lisa-as...@perso.be wrote:
> I'd rather understand what's going on, rather than simply never use it.
OK. Let's start from the beginning.
In sh and bash, anything that begins with a $ is potentially a
substitution, a.k.a. an expansion. The parser will tr
On Sun, Jul 11, 2021 at 11:09:10AM +0100, earnestly wrote:
> What appears to be happening is that the output from standard error is
> being mixed into the function handling standard out, even more
> surprisingly that xtrace output is also being consumed and filtered as
> well.
First, xtrace (set -
On Thu, Jul 15, 2021 at 05:28:04PM +0200, Léa Gris wrote:
> Le 15/07/2021 à 16:36, Gabríel Arthúr Pétursson écrivait :
> > Hi all,
> >
> > Executing the following results in a fierce crash:
> >
> > $ bash -c '{0..255}.{0..255}.{0..255}.{0..255}'
>
> Brace expression expands all the value in
On Sat, Jul 24, 2021 at 04:35:30PM +0200, Jean-Jacques Brucker wrote:
> Planning to use the /$"string/" feature in my bash code made me think too
> much : https://github.com/foopgp/bash-libs/tree/main/i18n
The security problem with $"..." is known. Unfortunately, Chet seems
set on the idea that $
On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Description:
> An extglob like +(!(x))y causes Bash to freeze with a 100% CPU
> utilization.
> At the first glance the freeze doesn't seem to depend on the
> (non-)existence of
On Tue, Jul 27, 2021 at 11:42:02PM +, Van Klaveren, Brian N. wrote:
> [bash-test@227f958499c1 ~]$ cat sourceme
> #!/bin/bash
> FOO=bar
> FOO=bar2
> set -a
> env | grep FOO
You probably want to put set -a at the top, before the variables are
set. The -a flag isn't retroactive. It only applies
On Mon, Aug 09, 2021 at 01:08:32PM -0400, Gyorgy Matyasfalvi wrote:
> Machine: ia64
> OS: hpux11.31
> Compiler: cc
> Compilation CFLAGS: -O -I/usr/local/include -D_XOPEN_SOURCE_EXTENDED +DD64
> uname output: HP-UX sovmh352 B.11.31 U ia64 1429105484 unlimited-user
> license
> Machine Type: ia64-hp-h
On Mon, Aug 09, 2021 at 05:35:56PM -0400, Franklin, Jason wrote:
> Should bash, invoked with "--posix" or as "sh", omit the special
> treatment of variables such as GROUPS?
I would say no. Using all-caps variable names is a bad idea for
precisely this reason -- you never know when it'll be someth
On Mon, Aug 09, 2021 at 10:00:25PM -0400, Franklin, Jason wrote:
> I did not write the scripts in question. These were actually Debian
> package maintainer scripts that started failing.
>
> Perhaps I'll get a test added to "checkbashisms" that looks for this.
A bug report against that Debian pac
On Tue, Aug 10, 2021 at 02:26:56PM +0100, Joe Pater wrote:
> The attached bash script (named 'test'), when run on my laptop,
> produces the following output:
>
> xyzerg
>
> Instead of the expected:
>
> Aabergxyz
OK, let's see if we can reproduce that. My initial thought is carriage
return pois
On Wed, Aug 11, 2021 at 10:43:12AM -0400, Chet Ramey wrote:
> On 8/10/21 5:08 PM, Chris F.A. Johnson wrote:
> >
> > It would be nice if there were an option to allow * to expand sorted
> > by timestamp rather than aphabetically.
>
> When you say `timestamp' I assume you mean by last modification
On Wed, Aug 11, 2021 at 08:00:12PM -0400, Franklin, Jason wrote:
> This doesn't work unless it was recently fixed. A variation does...
>
> bash-5.0$ echo $BASH_VERSION
> 5.0.17(1)-release
> bash-5.0$ GROUPS=FOO bash -c 'echo $GROUPS'
> 1000
> bash-5.0$ GROUPS=FOO bash --posix -c 'echo $GROUPS'
>
On Fri, Aug 13, 2021 at 10:10:42AM -0400, Chet Ramey wrote:
> As long as you stick to things POSIX standardizes. Relevant here, the
> standard even includes a list of variables you should avoid using because
> various shells and applications use them.
Just out of curiosity, where is that? It's no
On Mon, Aug 16, 2021 at 10:35:12PM -0400, Dale R. Worley wrote:
> Back in the old, old days, there was a program named "glob" that did
> pathname expansions. So you wouldn't say
>
>cat *
>
> you'd say
>
>cat $( glob * )
Tcl still does it that way. Not with that syntax, but the command
On Tue, Aug 17, 2021 at 10:26:21AM +0300, Oğuz wrote:
> On Tue, Aug 17, 2021 at 6:31 AM Greg Wooledge wrote:
> > An option to change the glob sorting order would actually be useful,
> > not for a large number of scripts, but for a very specific problem domain
> > where th
On Tue, Aug 17, 2021 at 01:02:06PM +0200, Osipov, Michael (LDA IT PLM) wrote:
> this is basically the same issue as I reported in readline:
> https://lists.gnu.org/archive/html/bug-readline/2021-08/msg0.html
As Chet said in that message, you have misinterpreted the POSIX
documentation.
> The
On Tue, Aug 17, 2021 at 04:03:17PM +0200, Osipov, Michael (LDA IT PLM) wrote:
> Am 2021-08-17 um 15:53 schrieb Greg Wooledge:
> > What version of HP-UX? What is the actual error you're getting?
>
> Latest and greatest: 11.31 v3
>
> > I only have access to certain o
On Tue, Aug 17, 2021 at 07:30:45AM -0700, L A Walsh wrote:
> The pairs are about 4 related operations. If you let P = the oPerator
> then the odd lines are about ':P' and the even lines are about 'P' (no
> colon).
> The Pairs from 1-4 are about the operators: '-', '=', '?', '+'
>
> Pair 4 shows e
On Tue, Aug 17, 2021 at 06:03:36PM +0300, Ilkka Virta wrote:
> I have this in the configure script:
>
> if test $ac_compiler_gnu = yes; then
> GCC=yes
> else
> GCC=
> fi
>
> I don't know which part of autoconf exactly generates it.
It comes from the AC_PROG_CC macro. On my system, this brin
On Thu, Aug 19, 2021 at 10:30:39AM -0400, Chet Ramey wrote:
> On 8/19/21 9:41 AM, Léa Gris wrote:
> > This will fail because of questionable design decision of having a mutable
> > argument format:
> >
> > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
> >
> > Note how the fo
1 - 100 of 1875 matches
Mail list logo
