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
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 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
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 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 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 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 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 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 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
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 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
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
> 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 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
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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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]:+
e from November:
Subject: foo=$*: ^A and DEL are prefixed or removed
http://lists.gnu.org/archive/html/bug-bash/2017-11/msg00107.html
If I read the commit message correctly, this looks like a fix for it:
http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=32dc2bf525399a80ef098bcf852331bc276c7ce8
--
Ilkka Virta / itvi...@iki.fi
in PATH, but if it's a
function, it seems to require the correct case. Sort of confusing, really.
--
Ilkka Virta / itvi...@iki.fi
he globs match
regardless of lettercase (it would also make a* match A).
--
Ilkka Virta / itvi...@iki.fi
t;; else echo
"$f <= b"; fi; done)"
Here, there are no quotes in the string to be compared, you've just
quoted the string on the left-hand side. The quotes are removed as usual
before the string is compared.
echo "$(for f in a b c; do if [[ '"$f"&#x
ange to that particular error condition, without changing
the overall behaviour.
2 would have my preference.
--
Ilkka Virta / itvi...@iki.fi
n/sh .
In the end it does get interpreted as a shell script, in both cases.
https://unix.stackexchange.com/questions/373223/which-shell-interpreter-runs-a-script-with-no-shebang
--
Ilkka Virta / itvi...@iki.fi
after "$(tput sgr0)". You probably don't have anything to
the right of the cursor at that point, so it'll only reset the color.
--
Ilkka Virta / itvi...@iki.fi
.e. ** looks through the link, but doesn't recurse
through it? Did I get that right?
That does seem somewhat surprising. The documentation on globstar
doesn't seem to mention anything about behaviour re. symlinks either.
--
Ilkka Virta / itvi...@iki.fi
(It seems the online manual is an older version than that in git, but I
didn't see this mentioned in the devel version of the manual either.)
[1] https://www.gnu.org/software/bash/manual/html_node/Shell-Parameters.html
[2]
https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html
--
Ilkka Virta / itvi...@iki.fi
sion of the script below looks
horribly unreadable.
the problem seems to be one of the operator
«!» in
a «=~» conditional because when testing this same notation with other
conditions
it does not seem to have an error.
You can hit that in other ways, too, e.g.:
falsy_echo() { echo &q
On 31.5. 02:20, L A Walsh wrote:
Ilkka Virta wrote:
On 22.5. 00:17, Uriel wrote:
As you know, a conditional is of the type:
if [[ EXPRESSION ]]; then TRUE CONDITION; else ALTERNATIVE RESULT; fi
Or with logical operators and groups:
[[ EXPRESSION ]] && { TRUE CONDITION; } || { ALT
like a redirection. But in some cases you might want the filename
prefixed with a string, e.g.:
somecmd --file=<(echo something)
Ksh's behavior makes that impossible.
--
Ilkka Virta / itvi...@iki.fi
"$1" ' sh -a -bcd
hello; done
dash : 2 3 3 3 3 hello
busybox sh: 2 3 3 3 3 hello
bash : 2 2 2 3 3 hello
ksh93 : 2 2 2 3 3 hello
zsh : 1 2 2 2 3 hello
--
Ilkka Virta / itvi...@iki.fi
file and then try the
above with and without the #.
--
Ilkka Virta / itvi...@iki.fi
fore parsing the number, re-attach after.
--
Cases are always threesome:
Best case, Worst case, and Just in case
--
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
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
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. '
; 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
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
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
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
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
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
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
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
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
single segment, I'd say it's broken.
--
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
b c d)
ashift somearray 2
--
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
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
/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
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
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
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
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
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
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
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
)) # -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
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
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
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
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
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
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
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
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 ( '+', '*'
at
confusingly) but should the reader of the manual be assumed to know the
options supported by BSD utilities?
--
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
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
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
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
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
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
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
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
various
*BSD:s and Solaris, so even if not standard, it's not like it's Linux-only.
--
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
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
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
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
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
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 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 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
1 - 100 of 114 matches
Mail list logo
