add a way to declare global variables
Good day, The new feature, associative arrays in bash 4.0 was very useful but I can't find any way to declare them as global when declaring inside a function. By default all variables are set local when using declare and typeset and there are no other ways to declare an associative array but through the said functions. I hope the development team will also consider adding a way in bash to declare global variables inside a function perhaps either with an option in typeset or declare like -g (same as zsh) and/or a builtin function like global as similar to local. Cheers, konsolebox
best way to test for empty dir?
Hi,
Does anyone know a more elegant way to check for file existence?
Something that does not fork a subshell. And is also more readable
maybe. And is obviously not much longer.
empty_dir()
{
test "x$(echo $1/*$2)" = "x$1"'/*'"$2"
}
Warning: I find neither "noglob" nor "ls" elegant, sorry!
Re: best way to test for empty dir?
On Thu, Dec 10, 2009 at 05:31:20PM +, Marc Herbert wrote:
> Does anyone know a more elegant way to check for file existence?
> Something that does not fork a subshell. And is also more readable
> maybe. And is obviously not much longer.
shopt -s nullglob
files=(*)
if (( ${#files[*]} == 0 )); then ...
shopt -u nullglob
> Warning: I find neither "noglob" nor "ls" elegant, sorry!
Well, some people like doing it this way:
files=(*)
if [[ ! -e ${files[0]} ]]; then ...
But:
1) There's a race condition between the initial enumeration and the
check of the first element.
2) It fails to detect dotfiles (do you also consider "dotglob"
inelegant?).
3) I personally find it even more of a hack than enabling nullglob.
Re: best way to test for empty dir?
On Thu, 10 Dec 2009 17:31:20 +
Marc Herbert wrote:
> Hi,
>
Hello
> Does anyone know a more elegant way to check for file existence?
> Something that does not fork a subshell. And is also more readable
> maybe. And is obviously not much longer.
>
> empty_dir()
> {
> test "x$(echo $1/*$2)" = "x$1"'/*'"$2"
> }
>
>
> Warning: I find neither "noglob" nor "ls" elegant, sorry!
>
Maybe you want the Chris F.A Johnson's implementation [1]:
set -- "/tmp/emptydir"/*
[[ -f $1 ]] && echo non-empty || echo empty;
References:
[1]
http://www.issociate.de/board/goto/866027/checking_if_a_directory_is_empty.html
--
Matias A. Fonzo
Re: best way to test for empty dir?
On Thu, Dec 10, 2009 at 05:37:04PM -0200, Matias A. Fonzo wrote:
> Maybe you want the Chris F.A Johnson's implementation [1]:
>
> set -- "/tmp/emptydir"/*
> [[ -f $1 ]] && echo non-empty || echo empty;
>
> References:
> [1]
> http://www.issociate.de/board/goto/866027/checking_if_a_directory_is_empty.html
The -f in the [[...]] should be -e, or it may give erroneous results if
the first thing matched by the glob happens to be a subdirectory (or
anything other than a plain file).
It's just a positional-parameter variant of:
files=("/tmp/emptydir"/*)
if [[ -e ${files[0]} ]] ...
Has the disadvantage that it clobbers the positional parameters, which
maybe you still want. Has the advantage that it'll work in ksh88,
which doesn't support the array=(...) syntax. They're both non-POSIX
though (due to the [[...]]). Of course, the PP variant is easier to
convert into a working POSIX version, since POSIX has no guarantee of
arrays.
Re: best way to test for empty dir?
On Thu, 10 Dec 2009, Marc Herbert wrote:
> Does anyone know a more elegant way to check for file existence?
> Something that does not fork a subshell. And is also more readable
> maybe. And is obviously not much longer.
>
> empty_dir()
> {
> test "x$(echo $1/*$2)" = "x$1"'/*'"$2"
> }
>
>
> Warning: I find neither "noglob" nor "ls" elegant, sorry!
is_file()
{
for f
do
[ -f "$f" ] && return
done
return 1
}
is_file /path/to/dir/* || echo empty
--
Chris F.A. Johnson, webmaster
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Re: best way to test for empty dir?
Greg Wooledge writes:
> It's just a positional-parameter variant of:
>
> files=("/tmp/emptydir"/*)
> if [[ -e ${files[0]} ]] ...
This will still fail if the first file happens to be a dangling symlink.
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."
Re: best way to test for empty dir?
Chris F.A. Johnson wrote:
> On Thu, 10 Dec 2009, Marc Herbert wrote:
>
>> Does anyone know a more elegant way to check for file existence?
>> Something that does not fork a subshell. And is also more readable
>> maybe. And is obviously not much longer.
>>
>> empty_dir()
>> {
>> test "x$(echo $1/*$2)" = "x$1"'/*'"$2"
>> }
>>
>>
>> Warning: I find neither "noglob" nor "ls" elegant, sorry!
>
> is_file()
> {
> for f
> do
> [ -f "$f" ] && return
> done
> return 1
> }
>
> is_file /path/to/dir/* || echo empty
This fails if the directory contains a file called "*".
Re: best way to test for empty dir?
pk wrote:
>> is_file()
>> {
>> for f
>> do
>> [ -f "$f" ] && return
>> done
>> return 1
>> }
>>
>> is_file /path/to/dir/* || echo empty
>
> This fails if the directory contains a file called "*".
My bad, it works correctly. The only issue I see is maybe that "-e" would be
more appropriate than "-f" since the first (and perhaps only) element could
be a directory.
xtrace output on new file descriptor
I'm wondering if anyone has any tricks to preserve stderr on filedescriptor 2 and get xtrace output on a different file descriptor. I've pulled hair trying to get the redirection right for this but just come up with the right combination. I'd imagine it involves stashing away fd 2, duplicating fd 2 to a new fd and then restoring fd back from where it was stashed, or somesuch. So to be clear, I want stdout on fd 1, stderr on fd 2 (as they are normally) and then the xtrace output on some other fd, presumably 3. Ideas? b. signature.asc Description: This is a digitally signed message part
Re: xtrace output on new file descriptor
On 12/10/09 10:12 PM, Brian J. Murrell wrote: > I'm wondering if anyone has any tricks to preserve stderr on > filedescriptor 2 and get xtrace output on a different file descriptor. > > I've pulled hair trying to get the redirection right for this but just > come up with the right combination. I'd imagine it involves stashing > away fd 2, duplicating fd 2 to a new fd and then restoring fd back from > where it was stashed, or somesuch. > > So to be clear, I want stdout on fd 1, stderr on fd 2 (as they are > normally) and then the xtrace output on some other fd, presumably 3. > > Ideas? Nothing good. The next version of bash will allow you specify an arbitrary file descriptor where the xtrace output will be written. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: xtrace output on new file descriptor
On Thu, 2009-12-10 at 22:20 -0500, Chet Ramey wrote:
>
> Nothing good.
Pity.
> The next version of bash will allow you specify an arbitrary
> file descriptor where the xtrace output will be written.
Cool. I wonder how long it will take the distros to pick that up
though. Sure, I could build my own packages, but the distro/arch matrix
here makes that somewhat prohibitive.
I suppose by that same token trying to play with FDs so that:
foo() {
echo "this is a message the user should see on stdout"
echo "this is the function return value"
}
bar=$(foo)
echo "bar==$bar"
Yields:
$ foo.sh 2>/dev/null
this is a message the user should see on stdout
bar==this is the function return value
Is equally difficult? Or can I more easily play with FD duplication and
redirection to achieve that, even if it means adding a ">&word" at the
end of things I want on the real stdout?
b.
signature.asc
Description: This is a digitally signed message part
