Re: /dev/fd/62: No such file or directory
Greg Wooledge wrote:
On Wed, Apr 02, 2014 at 07:54:58AM +0300, Pierre Gaston wrote:
[[ -d $1 ]] && {
readarray entries<<<"$(cd "$1" && printf "%s\n" * 2>/dev/null)"
((${#entries[@]} < 3)) && return 0
That's unnecessarily complex.
why not simply: entries=("$1"/*) ?
Indeed -- I just got around to changing this (been an odd week)...
combining it with a hint from greg:
You need to activate nullglob and dotglob first, but yes, that would be
the way I'd recommend.
dotglob is already activated, nullglob is not. I thought about it
if nullblob is unset, then I'll always have 1 element in the array --
so I don't have to worry about coding for an 'unset' value.
So all I need do is test the first entry:
local -a entries=("$1"/*)
[[ ${entries[0]} == $1/* ]] && return 0
--- the $1 doesn't need quotes in [[]] and '*' won't expand or
am missing something? Thanks for the tip Pierre, I often
don't see forests because of all the trees...
Re: /dev/fd/62: No such file or directory
Linda Walsh writes:
> So all I need do is test the first entry:
>
>local -a entries=("$1"/*)
>[[ ${entries[0]} == $1/* ]] && return 0
>
> --- the $1 doesn't need quotes in [[]] and '*' won't expand or
> am missing something? Thanks for the tip Pierre, I often
> don't see forests because of all the trees...
The RHS of [[ has pattern matching applied on unquoted parts, so yes,
you probably want quotes around $1.
pgpLMqnvOrGcV.pgp
Description: PGP signature
Re: /dev/fd/62: No such file or directory
Chris Down wrote:
Linda Walsh writes:
So all I need do is test the first entry:
local -a entries=("$1"/*)
[[ ${entries[0]} == $1/* ]] && return 0
--- the $1 doesn't need quotes in [[]] and '*' won't expand or
am missing something? Thanks for the tip Pierre, I often
don't see forests because of all the trees...
The RHS of [[ has pattern matching applied on unquoted parts, so yes,
you probably want quotes around $1.
Pattern matching? Why doesn't '*' match anything then?
Do you mean pathname expansion? or are you thinking of the =~
operator? I.e. where would it match a pattern? It can't match
in the current directory, since it just failed a pathname
expansion in the line before. But for a regex, I thought you
needed '=~' ??
Re: /dev/fd/62: No such file or directory
Linda Walsh writes: > Pattern matching? Why doesn't '*' match anything then? I've no idea what you're doing, but: $ var='*bar*' $ [[ abarb = $var ]] $ echo $? 0 $ [[ aquxb = $var ]] $ echo $? 1 pgpUZ39g3TPmc.pgp Description: PGP signature
Re: /dev/fd/62: No such file or directory
On Sat, Apr 5, 2014 at 1:46 PM, Linda Walsh wrote:
>
>
> Chris Down wrote:
>
>> Linda Walsh writes:
>>
>>> So all I need do is test the first entry:
>>>
>>>local -a entries=("$1"/*)
>>>[[ ${entries[0]} == $1/* ]] && return 0
>>>
>>> --- the $1 doesn't need quotes in [[]] and '*' won't expand or
>>> am missing something? Thanks for the tip Pierre, I often
>>> don't see forests because of all the trees...
>>>
>>
>> The RHS of [[ has pattern matching applied on unquoted parts, so yes,
>> you probably want quotes around $1.
>>
>
> Pattern matching? Why doesn't '*' match anything then?
>
> Do you mean pathname expansion? or are you thinking of the =~
> operator? I.e. where would it match a pattern? It can't match
> in the current directory, since it just failed a pathname
> expansion in the line before. But for a regex, I thought you
> needed '=~' ??
>
> * matches everything and nothing, so you need to quote the whole thing
$ [[ foo == * ]] && echo true
true
your test will also fail if there is one file named "*" it' better to just
[[ -e ${entries[0]} ]]
Re: /dev/fd/62: No such file or directory
Pierre Gaston wrote:
your test will also fail if there is one file named "*" it' better to
just [[ -e ${entries[0]} ]]
Sigh...so you are saying that:
[[ ${entries[0]} == "$1/*" ]] && return 0
would fail if someone has a file named '*'.
Hmmm...and whether the file exists or not, 'entries' will
still have 'arg1/*' in it so I can test it without worrying
about an 'unset' error. It's not that I'm running with
-u set normally, but these scripts get called from
various contexts, so want to make sure they don't
suffer from things that I know are possible.
This script would normally only be called at login or
by some system-start scripts. Either way, the env
is fairly predictable at those points (e.g. - not likely
'nullglob'). But protecting against refs to "unset vars"
is necessary, as I've seen some scripts that start
with "bash -u" at the top. Though, in my particular
use case, if there was only a file named '*' in
the directory -- having it return 0 would be ok, as
this is used to decide whether or not to add a directory
to your PATH when bash is starting -- so even if '*'
was an executable, and it's the only thing in a 'dir',
I don't think that "not adding" that dir to the PATH
would be a problem, and it might be a positive (who
names files '*' and expects to invoke them via
the PATH?).
I have never used the [[ xxx == ?xx*xx ]] construct
to do matching. I would have defaulted to =~ and
used an RE... but I can see there might be times
the other might be useful...but I see it as bit
arcane and would likely still tend to use an RE,
instead, in my own code.
So thanks Chris for the fast reminder lesson (I vague
remember having known that in the past, but it wasn't
something I actively remembered)..
UTF-8 printf string formating problem
Hello, printf string format counts bytes instead of chars, which leads to broken output ... just try this: (/usr/bin/printf is broken too) $ echo $LANG us_US.UTF-8 $ printf "|%4s|\n" "aa" | aa| $ printf "|%4s|\n" "áá" (chars are a-acute) |áá| expected output: | áá| IMHO this is a big bug, because it breaks any non ASCII chars formating.
Re: UTF-8 printf string formating problem
Jan Novak writes: > printf string format counts bytes instead of chars, which leads to > broken output According to POSIX, printf's field width control is strictly in bytes, not characters.[0] > field width: > An optional string of decimal digits to specify a minimum field > width. For an output field, if the converted value has fewer > bytes than the field width, it shall be padded on the left (or > right, if the left-adjustment flag ( '-' ), described below, has > been given) to the field width. By that definition, this is expected behaviour. You will also find this behaviour in pretty much any POSIX-y tool that uses format strings (mawk/gawk do it). I don't have much of an opinion on whether this behaviour is right or wrong in the context of bash, but if this behaviour is changed, I think it should be done under another format character, rather than changing %s (or changing behaviour when not in POSIX-compliance mode). 0: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html pgpCnrTE6KfhH.pgp Description: PGP signature
Re: UTF-8 printf string formating problem
Jan Novak writes: > IMHO this is a big bug, because it breaks any non ASCII chars formating. It is consistent with printf(3). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
