On Tue, Mar 22, 2022 at 11:52 PM L A Walsh wrote:
> On 2022/03/21 05:45, Andreas Luik wrote:
> > Description:
> > Bash fails to correctly test for parameter to be unset or null
> when the parameter is an array reference [*] or [@].
> >
> > Repeat-By:
> >
> > myvar[0]=
> > echo "${myvar[0]:+
On Sat, Feb 12, 2022 at 8:25 PM David Hobach wrote:
> I guess it closes the function and {echo is interpreted as string or so,
> but that is probably not all (testCode is e.g. never executed).
>
Let's see if I get this right.
Removing the irrelevant parts, your code is pretty much this:
func()
On Fri, Nov 19, 2021 at 12:53 PM Marshall Whittaker <
marshallwhitta...@gmail.com> wrote:
> You could argue that bash should parse filenames globbed from * that start
> with - and exclude them specifically,
>
Or a shell could prepend ./ to all globs relative globs. Not sure if that
would change t
On Wed, Nov 17, 2021 at 2:42 PM Marshall Whittaker <
marshallwhitta...@gmail.com> wrote:
> [marshall@jerkon]{04:09 AM}: [~/bashful] $ touch -- '--version'
> [marshall@jerkon]{04:09 AM}: [~/bashful] $ rm *
> rm (GNU coreutils) 8.30
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3
On Wed, Nov 17, 2021 at 1:33 PM Andreas Schwab
wrote:
> On Nov 17 2021, Michael J. Baars wrote:
>
> > When -N stands for NEW, and touch (-am) gives you a new file
>
> It doesn't. The file hasn't been modified after it was last read.
>
touch creates the given file if it doesn't previously exist.
On Mon, Nov 15, 2021 at 5:21 AM Greg Wooledge wrote:
>relatime
> Update inode access times relative to modify or change
> time.
> Access time is only updated if the previous access time was
> ear‐
> lier than the current modify or change t
On Fri, Nov 12, 2021 at 3:22 PM Mischa Baars
wrote:
> It is how my makefiles work :)
>
Sounds to me you're not using Make, but some self-made tool, so the files
you have would be more
properly called build scripts or whatever, and not makefiles.
On Fri, Oct 29, 2021 at 1:01 AM elettrino via Bug reports for the GNU
Bourne Again SHell wrote:
> user@machine:~$ USER_INPUT='x[$(id>&2)]'
> user@machine:~$ test -v "$USER_INPUT"
> uid=1519(user) gid=1519(user) groups=1519(user),100(users)
>
What you're doing here, is having the user name a vari
On Mon, Oct 4, 2021 at 4:46 PM Chet Ramey wrote:
> Bash reports the error it gets back from execve. In this case, it's
> probably that the loader specified for the executable isn't present on your
> system.
>
OTOH, for a script, Bash checks to see if the problem is with the
interpreter and repor
What do you get with [![:digit:]] then? It seems to work the same with both
! and ^ here:
$ now=$EPOCHREALTIME
$ echo "${now%[^[:digit:]]*}" "${now#*[^[:digit:]]}"
1629544775 183030
$ echo "${now%[![:digit:]]*}" "${now#*[![:digit:]]}"
1629544775 183030
On Fri, Aug 20, 2021 at 10:30 PM hancoope
On Thu, Aug 19, 2021 at 4:12 PM hancooper wrote:
> On Thursday, August 19, 2021 12:58 PM, Léa Gris
> wrote:
> > (LC_NUMERIC=C; echo "$EPOCHREALTIME")
>
> the unix time stamp is merely the number of
> seconds between a particular date and the epoch. Technically, it should
> be pointed out
> that
On Thu, Aug 19, 2021 at 5:49 AM Koichi Murase
wrote:
> FYI, zsh provides this feature for associative arrays with the syntax
> ${(kv)assoc} or ${(@kv)assoc}. Note that Bash-5.1 already has a
> similar feature ${array[@]@K}, but the substitution result is quoted
> so cannot be directly used for th
On Tue, Aug 17, 2021 at 5:40 PM Greg Wooledge wrote:
> I'm still wondering what issue the OP is actually seeing. If they claim
> that changing ${GCC+-stuff} to ${GCC:+-stuff} in some file fixes things,
> and if they also claim that *something* is setting the GCC variable to
> the empty string ra
On Tue, Aug 17, 2021 at 5:36 AM Dale R. Worley wrote:
>cat $( glob * )
>
> where glob would get one argument, "*", and output a list of file
> names. A glob-by-modification-date program would be a better solution
> for this need, IMHO.
>
So that program would have to duplicate the globbing
On Sun, Aug 15, 2021 at 2:00 AM George Nachman wrote:
> Defining an alias named `done` breaks parsing a for loop that does not have
> an `in word` clause.
>
alias done=""
>
Works for me:
$ set -- a b c
$ alias done='echo hi; done'
$ for x do done
hi
hi
hi
Not that I think it's a good idea to
On Thu, Jun 24, 2021 at 5:20 PM Chet Ramey wrote:
> On 6/24/21 4:09 AM, Ilkka Virta wrote:
>
> > But 3.4 Shell Parameters is a bit confusing: "Word splitting is not
> > performed, with the exception of "$@" as explained below."
>
> This means that
On Thu, Jun 24, 2021 at 10:53 AM Alvin Seville
wrote:
> Hello! I want to understand why the following code doesn't produce any
> error:
> set -- "a b" "c"
> a="$@"
> ? I expected smth like: main.sh: line 2: b: command not found due to word
> splitting according to documentation
> <
> https://www
On Sun, Jun 6, 2021 at 2:49 PM Léa Gris wrote:
> Either you're acting in bad faith, or you're so confused by your
> gender-neutral delusion that you don't remember that in normal people's
> grammar, "they" is a plural pronoun.
>
Argh, no, that's just an example of the fact that I can't read. Sor
On Sun, Jun 6, 2021 at 1:31 PM Ilkka Virta wrote:
> Personally, I'd just want an option to always make . and .. hidden from
> globs. Or rather,
> to never generate . or .. as a pathname component via globbing. But
> without affecting
> other behaviour, like dotglob, and wi
> Can you write a set of rules that encapsulates what you would like to see?
> Or can the group?
>
I think it's a bit weird that !(.foo) can match . and .. when * doesn't.
The other means roughly "anything here", and the other means "anything but
.foo here",
so having the latter match things the
On Sun, Jun 6, 2021 at 5:50 AM Léa Gris wrote:
> Le 05/06/2021 à 18:47, John Passaro écrivait :
> > I can see a couple reasons why it would be a good thing, and in the con
> > column only "I personally don't have time to go through the manual and
> make
> > these changes". but I'd happily upvote
On Thu, Apr 29, 2021 at 4:18 AM Chet Ramey wrote:
> Maybe, but it's never worked that way and was never intended to. You can
> get what you need using eval:
>
> eval echo \{1..${i}}
>
BTW, was there some background to why they're ordered like this? I'm not
sure if I have heard the story, and did
What a 'name' is, is further defined under "Definitions": "name: A word
consisting solely of letters, numbers, and underscores, ..."
But it seems you're right that it doesn't say the locale's idea of letters
isn't taken into account. Some other shells do accept those.
On Mon, Apr 19, 2021 at 4:28
On Tue, Apr 6, 2021 at 6:53 PM Greg Wooledge wrote:
> In that case, I have no qualms about proposing that unset 'a[@]' and
> unset 'a[*]' be changed to remove only the array element whose key is
> '@' or '*', respectively, and screw backward compatibility.
>
That also seems to be what Ksh and Zs
On Tue, Apr 6, 2021 at 6:13 PM Greg Wooledge wrote:
> As a counter-proposal, Chet could entirely remove the special meaning
> of unset 'a[@]' and introduce a new option to unset which would take
> its place. It appears -a is not yet used, so that would be a good pick.
>
Unless I missed somethin
On Thu, Apr 1, 2021 at 7:59 PM Robert Elz wrote:
> Alternatively
> d=( $( ls -d /usr/src/pkg/*/$1 ) )
> or just
> d=( $( printf %s\\n /usr/src/pkg/*/$1 ) )
>
> Just to be sure.Personally I'd do
>
> set -- /usr/src/pkg/*/$1
>
Just the glob is fine in the array assignme
On Fri, Apr 2, 2021 at 2:04 AM Robert Elz wrote:
> chet.ra...@case.edu said:
> | Yes, you need a list terminator so that `done' is recognized as a
> reserved
> | word here. `;' is sufficient. Select doesn't allow the `done' unless
> it's
> | in a command position.
>
> isn't really all that
On Tue, Mar 30, 2021 at 1:40 AM Eric Cook wrote:
> Its just when populating that array dynamically with another array
> if that second array didn't contain `v1' hypothetically, the array gets
> shifted to
>
> a=( [k1]=k2 [v2]=k3 [v3]= )
> which i would imagine to be unexpected for the author of t
On Mon, Mar 29, 2021 at 1:56 AM Greg Wooledge wrote:
> Python is different:
>
> >>> y = ["a", "b", "c", "d"]
> >>> dict(zip(y[::2], y[1::2]))
> {'a': 'b', 'c': 'd'}
> >>> x = ["a", "b", "c"]
> >>> dict(zip(x[::2], x[1::2]))
> {'a': 'b'}
>
> It seems to discard the last (unmatched) value. Also, d
On Sun, Mar 28, 2021 at 10:16 AM Oğuz wrote:
> That an idea was borrowed from another shell doesn't mean it should be
> implemented the same kludgy way. Besides, bash doesn't offer compatibility
> with zsh.
>
You don't think the realm of POSIX-ish shells already has enough
incompatibilities
and
On Wed, Mar 24, 2021 at 9:38 PM L A Walsh wrote:
> Hmmm...Now that I try to show an example, I'm not getting
> the same results. Grrr. Darn Heizenbugs.
>
Just remember that if you test with printf, it always prints at least once,
which makes it look exactly as if it got an empty string arg
The lowercase 'ignoreeof' variable appears to act as a sort of a synonym to
the uppercase 'IGNOREEOF'. Both seem to call into 'sv_ignoreeof', and the
latter one set takes effect. I can't see the lowercase one documented
anywhere, is this on purpose?
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 -p.
> It would be nice if it did, though. Newlines, carriage returns, escape
> characters, etc.
>
It does in
On Mon, Jan 18, 2021 at 12:02 AM Martin Schulte
wrote:
> To be exact, this is already caused by a Unix Kernel - strings passed by
> the exex* system calls are null terminated, too. As it is the default in
> the C programming language. Thus you can't pass a null byte in an argument
> when invoking
>
> Lots of things "could be useful" if only they worked, but they don't work,
> so you don't do them.
>
Yes, and it does work in 4.4.
> The fact that this undocumented, unsupported hack "appeared to work"
> with certain inputs in bash 4.4 is just an unfortunate event, unless
> Chet decides to m
On Wed, Jan 13, 2021 at 7:49 PM Greg Wooledge wrote:
> On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> > $ declare -n b=a[0]
>
> I can't see any documentation that supports the idea that this should
> be allowed in the first place.
>
It's arguably useful though, and works in 4.4 (wit
On Sat, Jan 9, 2021 at 9:14 AM Robert Elz wrote:
> Not "all" other shells, most don't implement exponentiation at all,
> since it isn't a standard C operator.
>
Which also means that the statement about the operators being "same as in
the C language" doesn't really help figure out how this parti
On Sat, Jan 9, 2021 at 7:22 AM Oğuz wrote:
> 9 Ocak 2021 Cumartesi tarihinde Hyunho Cho yazdı:
> > $ echo $(( -2 ** 2 )) # only bash results in 4
> > 4
> `bc' does that too. Here's another trivial side effect of implementing
> unary minus using binary minus:
>
Note that bina
On Fri, Jan 8, 2021 at 5:44 PM Chet Ramey wrote:
> On 1/8/21 10:24 AM, Oğuz wrote:
> > This situation is why bash-5.0 introduced the `assoc_expand_once'
> option.
> > But it allows arbitrary command injection.
>
> If you want to run array keys through word expansions, this is one
> potential
On Fri, Jan 8, 2021 at 4:06 PM Chet Ramey wrote:
> No. `declare -p' does not accept assignment statements.
>
The synopsis in the documentation doesn't make it clear, though. It shows
only one case with -p and assignment, while the similar case of export -p
is listed separately from the other for
On Mon, Dec 28, 2020 at 3:16 PM Greg Wooledge wrote:
> The problem is that the parent bash (the script) doesn't know, and
> cannot know, that the command was stillborn. Only the child bash
> process can know this, and by the time this information has become
> available, the parent bash process h
limiter or a
newline." shouldn't make
the text significantly heavier, given it already uses almost double the
letters to spell out how the words
are assigned to the names given in order.
On Wed, Dec 23, 2020 at 4:44 PM Chet Ramey wrote:
> On 12/22/20 9:13 AM, Ilkka Virta wrote:
> &
Arguably it's a bug that 'help read' doesn't mention the effect of
backslashes, other than what can be extrapolated from the description of
-r. It only says "The line is split into fields _as with word splitting_",
but word splitting doesn't recognize backslashes as special. It should not
be necess
On Tue, Nov 24, 2020 at 12:07 AM Jetzer, Bill
wrote:
> ((--x)) || echo "err code $? on --x going
> from $i to $x";
>
> err code 1 on ++x going from -1 to 0
>
That's not about --x, but of the ((...)) construct:
"" (( expression ))
The arithmetic expression is eval
On Tue, Nov 17, 2020 at 4:07 PM Pierre Colombier via Bug reports for the
GNU Bourne Again SHell wrote:
> #2
> pierre@zebulon: ~ $ (set -e ; echo A ; false ; echo B ) && echo C.$?
> #3
> pierre@zebulon: ~ $ bash -c 'set -e ; echo A ; false ; echo B ' && echo
> C.$?
If it's not a bug, I thi
On Wed, Sep 30, 2020 at 5:53 PM Michael Green wrote:
> The included short script when run with the following command results
> in execve "E2BIG (Argument list too long) errors".
>
> * The number of arguments can be tuned down to "seq 1 23694" and it
> still occurs, but any lower and it disappears
On Sat, Aug 29, 2020 at 11:13 PM Bruce Lilly wrote:
> It's a bit more complicated than that; if, for example, some excerpt ended
> up in regression tests, there would be a question about whether or not
> there was a copyright violation. As I understand the GPL (IANAL), it
> requires all parts of
On Sat, Aug 29, 2020 at 9:56 PM Bruce Lilly wrote:
> Please don't assume that something output by printf (without quoting) for
> clarity is representative of actual expansion by the shell when properly
> quoted.
>
If you don't want people to assume (and you shouldn't, if you want them to
help yo
On Fri, Aug 28, 2020 at 4:04 PM Gabriel Winkler
wrote:
> # Causes error
> test=0
> ((test++))
> echo $?
> 1
>
It's not an error, just a falsy exit code. An error would probably give a
message.
But to elaborate on the earlier answers, the value of the post-increment
expression
var++ is the _old_
On Mon, Aug 17, 2020 at 3:53 PM Steven McBride wrote:
> 'echo "$(<\"filename\")"' fails with No such file or directory
>
Quotes inside $() are independent from the ones outside. If you escape
them, you get literal quotes as part of the filename.
$ echo hello > '"filename"'
$ echo "$(<\
On 6.8. 15:59, Chet Ramey wrote:
On 8/6/20 8:13 AM, Ilkka Virta wrote:
I think they meant the case where all the files matching the given
beginning have a longer prefix in common. The shell expands that prefix to
the command line after asking to show all possibilities.
Only if you set the
common part anyway, and it might as well
do it first, without asking.
(Which just so happens to be what Zsh does...)
--
Ilkka Virta / itvi...@iki.fi
It does seem to have a subscript on the LHS, but it didn't work as one.
To be in line with a plain scalar assignment, the braces should probably
not be expanded here.
--
Ilkka Virta / itvi...@iki.fi
e available in the script itself.
The message also seems to be much briefer for an interactive shell or a
-c script. At least the latter ones might also benefit from the longer
error message.
--
Ilkka Virta / itvi...@iki.fi
-r file
do
if ! $(echo "$file" | grep -E "*.so$"); then continue; fi
echo "library: $file"
done
Are you trying to find the .so files, or run them for some tests?
Because it looks to me that you're running whatever that command
substitution outputs, and not all dynamic libraries are made for that.
--
Ilkka Virta / itvi...@iki.fi
various
*BSD:s and Solaris, so even if not standard, it's not like it's Linux-only.
--
Ilkka Virta / itvi...@iki.fi
initially for testing.
It always struck me as odd that Bash used such a small read of 128
bytes. Most of the GNU utils I've looked at on Debian use 8192, and a
simple test program seems to indicate glibc's stdio reads 4096 bytes at
one read() call.
--
Ilkka Virta / itvi...@iki.fi
nd if you need
that often, I suppose you could run it from PROMPT_COMMAND:
/tmp$ PROMPT_COMMAND='cd .'
/tmp$ mkdir old
/tmp$ cd old
/tmp/old$ mv /tmp/old /tmp/new
/tmp/new$ echo $PWD
/tmp/new
--
Ilkka Virta / itvi...@iki.fi
itly, without a glob in the final part of the path,
they should probably still be allowed, even if the word was otherwise a
glob. (e.g. if something like foo/*/. happened to be useful in some case.)
--
Ilkka Virta / itvi...@iki.fi
se that's how printf %q outputs an empty string.
read -r -a a< <(printf "%q " {Z..a})
my -p a
declare -a a=([0]="Z" [1]="\\[" [2]="''" [3]="\\]" [4]="\\^" [5]="_"
[6]="\\\`" [7]="a")
--
Ilkka Virta / itvi...@iki.fi
al use case for such a range?
It doesn't seem to even generalize from that if you go beyond letters,
so you can't do stuff like generating all the printable ASCII characters
with it in Bash.
--
Ilkka Virta / itvi...@iki.fi
quotes with the exception that single quotes between the
MAGIC_WORDs need not be escaped.
Pardon my naïveté, does any such feature exist or are there good ways to
accomplish this? If not, is this something that could feasibly be
implemented? Would it be desirable?
Thanks,
Patrick
--
Ilkka Virta / itvi...@iki.fi
users run (other) unrestricted shells,
or any of the various programs that allow forking off other programs,
including find, xargs, many editors, etc.
--
Ilkka Virta / itvi...@iki.fi
le of days,
starting at this message from last Friday:
https://lists.gnu.org/archive/html/bug-bash/2019-09/msg00042.html
--
Ilkka Virta / itvi...@iki.fi
at
confusingly) but should the reader of the manual be assumed to know the
options supported by BSD utilities?
--
Ilkka Virta / itvi...@iki.fi
On 21.9. 21:55, Dmitry Goncharov wrote:
On Sat, Sep 21, 2019 at 12:34:39PM +0300, Ilkka Virta wrote:
[[:space:]]*?(a)b isn't a well-defined POSIX ERE:
9.4.6 EREs Matching Multiple Characters
The behavior of multiple adjacent duplication symbols ( '+', '*'
space:]]*?(a)b isn't a well-defined POSIX ERE:
9.4.6 EREs Matching Multiple Characters
The behavior of multiple adjacent duplication symbols ( '+', '*', '?',
and intervals) produces undefined results.
https://pubs.opengroup.org/onlinepubs/9699919799.2018ed
nd
then mention that the ^ and $ anchors could be used.
I know the usual regex behavior is to find a match anywhere within the
value, but since it's exactly the opposite of how regular pattern
matches work, it's probably worth mentioning in some way. (Though I do
think it's bett
27; anywhere in its
value", so the text does recognize the zero-width-matching parts don't
affect what matches. (I suppose they would affect what goes to
BASH_REMATCH[0], but the text doesn't mention that.)
I think it would be a better example with the anchored version also
presented for comparison.
--
Ilkka Virta / itvi...@iki.fi
ly matters when starting a new process (as far as I know).
An example that would actually run and demonstrate the issue might make
it easier to see what's actually going on.
--
Ilkka Virta / itvi...@iki.fi
I've been led to believe that the shell
in general is rather slow, and almost any other language would be better
if that is of concern. (awk, Perl, what have you.)
--
Ilkka Virta / itvi...@iki.fi
le.txt:
I tried with Bash and some other shells, but couldn't find one where the
result was different. Did I miss something?
--
Ilkka Virta / itvi...@iki.fi
sh | tail -1
ii ksh93u+20120801-3.4 amd64Real, AT&T version of the Korn
shell
wooledg:~$ ksh -c 'echo ${.sh.version}'
Version AJM 93u+ 2012-08-01
Seems kinda weird to continue calling it "ksh93" if it's being changed,
but I don't make the decisions.
--
Ilkka Virta / itvi...@iki.fi
)) # -1230
echo $(( 10 * 10#-008 )) # -80
echo $(( 10 * 10#1+23 )) #10*1 + 23 = 33
echo $(( 10# )) # error
$ ./bash test.sh
-1230
-80
33
test.sh: line 5: 10#: no digits in number (error token is "10#")
$ ksh test.sh
-1230
-80
33
0
--
Ilkk
above seems to work in this case because 10# is
treated as a constant number by itself (with a value of 0), and then the
1 is subtracted.
try also e.g.:
$ echo $((10#))
0
echo $((0-10#-1)) # -1 UNEXPECTED. Would expect 1.
So this is 0-0-1 = -1
--
Ilkka Virta / itvi...@iki.fi
ript
$ (( a[i]++ ))
Thu Jun 6 16:46:12 EEST 2019
$ (( 'a[$i]++' ))
Thu Jun 6 16:46:18 EEST 2019
$ (( 'a[i]++' ))
Thu Jun 6 16:46:31 EEST 2019
So if we want "valid" values in the index to work, and invalid ones to
not do anything nasty, I can't seem to find a case where quotes would
help with that.
--
Ilkka Virta / itvi...@iki.fi
On 5.6. 17:05, Chet Ramey wrote:
On 6/4/19 3:26 PM, Ilkka Virta wrote:
If the bad user supplied variable contains array indexing in itself, e.g.
bad='none[$(date >&2)]' then using it in an arithmetic expansion still
executes the 'date', single quotes or not (the
o "$(( 'a[$i]' ))"
bash: 'a[2]' : syntax error: operand expected (error token is "'a[2]' ")
Maybe it would be better to try to sanity-check any user-provided values
first:
$ case $var in *[^0123456789]*) echo "Invalid input" >&2; exit 1;; esac
$ (( a[var]++ )) # safe now?
--
Ilkka Virta / itvi...@iki.fi
separate line:
/bin/echo foo > "$i"
: "$(( i += 1 ))"
Some find that easier to read, too: the increment isn't "hidden" within
the other stuff on the command line.
--
Ilkka Virta / itvi...@iki.fi
ase Specification.
So I consider it as a bug still.
On 20.01.2019 18:18, Andreas Schwab wrote:
On Jan 20 2019, Andrey Butirsky wrote:
|$ unset 1a ||
||bash: unset: `1a': not a valid identifier
Use `unset -f'.
Andreas.
--
Ilkka Virta / itvi...@iki.fi
breaks the above mentioned rule.
$ touch .foo aa.foo; bash -O extglob -c 'echo ?(aa).foo'
aa.foo .foo
The change in Bash 5.0 also makes @(aa|) different from ?(aa) , even
though the distinction between those two doesn't appear immediately
obvious.
--
Ilkka Virta / itvi...@iki.fi
/bin/sh isn't Bash by
default on Debian and Ubuntu, so it might be you're just not running the
script with Bash.
--
Ilkka Virta / itvi...@iki.fi
1 ]] && printf '\e[30;47m%%\n\e[0m'; }
PROMPT_COMMAND=prompt_to_bol
(I stole the main parts from the answers in
https://unix.stackexchange.com/q/88296/170373 )
--
Ilkka Virta / itvi...@iki.fi
xpressions" too? Perhaps also explicitly noting the
clash with the binary operators in the descriptions of -a and -o, too.
Something along the lines of the attached patch.
I also think the description of the 3-argument test would be clearer
with numbering, so I added that too.
--
Ilkka Vi
b c d)
ashift somearray 2
--
Ilkka Virta / itvi...@iki.fi
t; /dev/null
write(1, "foo\n", 4)= 4
write(1, "bar\n", 4) = 4
+++ exited with 0 +++
--
Ilkka Virta / itvi...@iki.fi
single segment, I'd say it's broken.
--
Ilkka Virta / itvi...@iki.fi
sleep, if an
enabled-by-default builtin sleep is implemented. Just for those systems
that happen to have both GNU Bash and GNU coreutils installed.
--
Ilkka Virta / itvi...@iki.fi
On 21.8. 14:34, konsolebox wrote:
Also it's basically
people's fault for not reading documentation. One should be aware
enough if they enable the builtin.
Yes, if it's not enabled by default.
--
Ilkka Virta / itvi...@iki.fi
eep 1m 30s for 90 seconds). I didn't
see support for those in konsolebox's patch, so while that's not
conflicting syntax per se, the lack of that option might trip someone.
--
Ilkka Virta / itvi...@iki.fi
ou're considering special-casing just those three, I'd suggest
adding a-f and A-F too, for patterns matching hex digits.
So yeah, +1 from me.
--
Ilkka Virta / itvi...@iki.fi
d to glob in the shell, then an unquoted expansion is
what has to be used. How IFS affects word splitting isn't just about
$* , the issue is the same even if you only have one glob in a regular
variable.
--
Ilkka Virta / itvi...@iki.fi
tager/bash-install' isn't an
assignment, just a regular command line argument.
The paragraph about assignments could be expanded to say "This applies
also to regular command-line arguments that look like assignments." or
something like that.
--
Ilkka Virta / itvi...@iki.fi
On 1.8. 15:12, Greg Wooledge wrote:
On Wed, Aug 01, 2018 at 02:43:27PM +0300, Ilkka Virta wrote:
On both Bash 4.4.12(1)-release and 5.0.0(1)-alpha, a subarray slice like
${a[@]:0} expands to just one word if unquoted (and if IFS doesn't
contain a space):
This just reinforces the point
le words as
expected with both [@] and [*].
An expansion like that should in most cases be quoted,
but the current behaviour still seems a bit inconsistent.
--
Ilkka Virta / itvi...@iki.fi
; value="";
printf "<%s> " "$0" ${cond:+ "$value" }; echo;' ; done
<>
<>
<>
Or with multiple words inside:
$ for shell in bash dash ksh "zsh -y" ; do $shell -c 'cond=1; printf
"<%s> " "$0" ${cond:+"" "x" ""}; echo;' ; done
<> <>
<>
<> <>
It doesn't seem like a very good idea to rely on this, arrays would of
course work better.
Bash: GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
ksh:version sh (AT&T Research) 93u+ 2012-08-01
zsh: zsh 5.3.1 (x86_64-debian-linux-gnu)
dash: Debian's 0.5.8-2.4
--
Ilkka Virta / itvi...@iki.fi
On 10.7. 18:09, Chet Ramey wrote:
On 7/10/18 6:44 AM, Ilkka Virta wrote:
I think the problematic case here is when the number comes as input from
some program, which might or might not print a leading sign or leading
zeroes, but when we know that the number is, in any case, decimal.
E.g. '
s
yes
You might as well remove the backslashes, because they serve no purpose
here. If you thought they meant "word boundary" or something, you're
in the wrong language.
--
Ilkka Virta / itvi...@iki.fi
; printf "%s " $((a + 1)); done; echo' \
sh +159 +0159 -159 -0159
160 160 -158 -158
$ ksh --version
version sh (AT&T Research) 93u+ 2012-08-01
$ zsh --version
zsh 5.3.1 (x86_64-debian-linux-gnu)
On 10.7. 13:44, Ilkka Virta wrote:
I think the problematic case here is wh
fore parsing the number, re-attach after.
--
Cases are always threesome:
Best case, Worst case, and Just in case
--
Ilkka Virta / itvi...@iki.fi
1 - 100 of 114 matches
Mail list logo
