Re: best way to test for empty dir?
Matias A. Fonzo s...@dragora.org writes: A solution to check the broken symlink is: [ -e foo -o -L foo -a ! -e foo ] In which way is the last check not redundant? 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: add a way to declare global variables
Am 12.12.2009 02:11, schrieb Matthew Woehlke: konsolebox wrote: 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. I thought variables in functions were /always/ global unless declared local? It's the other way round. Regarding typeset and declare, the man page says: When used in a function, makes each name local, as with the local command. So within a function, typeset, declare, and local are synonyms. Using 'local' outside a function is an error, so IMHO this command is completely redundant. It _would_ make some sense, however, if its counterpart 'global' existed, as it could help clarify the intended usage of the variable. Bernd -- Bernd Eggink http://sudrala.de
Re: add a way to declare global variables
Am 10.12.2009 10:40, schrieb konsolebox: 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. I second that. I'm missing this feature badly. Presently, you can only get around this restriction by using a lot of ugly and dangerous 'eval's. Bernd -- Bernd Eggink http://sudrala.de
Re: add a way to declare global variables
On Sat, 12 Dec 2009, Bernd Eggink wrote: Am 12.12.2009 02:11, schrieb Matthew Woehlke: konsolebox wrote: 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. I thought variables in functions were /always/ global unless declared local? It's the other way round. Regarding typeset and declare, the man page says: When used in a function, makes each name local, as with the local command. So within a function, typeset, declare, and local are synonyms. Using 'local' outside a function is an error, so IMHO this command is completely redundant. It _would_ make some sense, however, if its counterpart 'global' existed, as it could help clarify the intended usage of the variable. Of the three, local is the only command I use. It says exactly what it does. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com === 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?
2009-12-11, 16:16(+00), Marc Herbert:
Sven Mascheck a écrit :
Chris F.A. Johnson wrote:
This has been discussed more than once in c.u.s; check the
archives.
and that's why we better discuss it here now?
I think Chris' message was more like: let's not discuss it at all and
just read the archives :-]
In case anyone is interested my winner (so far) is:
exists()
{
[ -e $1 -o -L $1 ]
}
$ exists =
bash: [: too many arguments
[ -e $1 ] -o [ -L $1 ]
(that one would still choke on '=' with the Bourne shell, note).
if exists foo/*; then
for f in foo/*; do
...
done
fi
[...]
Also, if you have the 'r' but not 'x' permission on 'foo', the
wildcard will expand, but the tests will fail. You don't need
the tests, you can do:
(
set -- foo/[*] foo/*
case $1$2 in
(foo/[*]foo/*) echo no non-hidden files or directory not readable;;
(*) echo some non-hidden files in here
esac
)
Or bash specific:
shopt -s nullglob dotglob
files=(foo/*)
(( ${#fil...@]} ))
zsh:
files=(foo/*(ND[1]))
(( $#files ))
--
Stéphane
Re: best way to test for empty dir?
2009-12-12, 10:21(+00), Stephane CHAZELAS:
[...]
exists()
{
[ -e $1 -o -L $1 ]
}
$ exists =
bash: [: too many arguments
[ -e $1 ] -o [ -L $1 ]
[...]
Sorry, I meant
[ -e $1 ] || [ -L $1 ]
--
Stéphane
Re: add a way to declare global variables
2009-12-12, 11:28(+01), Bernd Eggink: Am 10.12.2009 10:40, schrieb konsolebox: 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. I second that. I'm missing this feature badly. Presently, you can only get around this restriction by using a lot of ugly and dangerous 'eval's. [...] For information, zsh has the -g typeset option for that. -- Stéphane
Re: kill builtin incorrectly works with -s -n and -PGID options
2009-12-11, 06:17(-07), Eric Blake: According to Roman Rakus on 12/11/2009 6:08 AM: kill builtin incorrectly thinks that -PGID is signal name even if the signal name is set by -s or -n option. [rra...@dhcp-lab-170 ~]$ kill -s TERM -5032 bash: kill: 5032: invalid signal specification Not necessarily a bug. POSIX requires that portable shell use: kill -s TERM -- -5032 I don't think so. -- is only necessary as the first argument as in kill -- -5032. SUSv4: To avoid an ambiguity of an initial negative number argument specifying either a signal number or a process group, POSIX.1-2008 mandates that it is always considered the former by implementations that support the XSI option. It also requires that conforming applications always use the -- options terminator argument when specifying a process group, unless an option is also specified. ~~ So I'd say it's a bug. Now, pdksh, ash and their derivatives also have that bug (zsh and ATT ksh are OK), so the advice to use '--' in any case, in practice should be followed. -- Stéphane
Re: add a way to declare global variables
Am 12.12.2009 11:24, schrieb Bernd Eggink: Am 12.12.2009 02:11, schrieb Matthew Woehlke: konsolebox wrote: 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. I thought variables in functions were /always/ global unless declared local? It's the other way round. Regarding typeset and declare, the man page says: When used in a function, makes each name local, as with the local command. So within a function, typeset, declare, and local are synonyms. To avoid misunderstandings, let me add that you are right (only) with respect to variables being used _without_ declaration. The problem is that associative arrays are the only kind of variables that _must_ be declared, since something like a[foo]=bar without a preceding declaration would create an indexed array (and set a[0] to bar). Bernd -- Bernd Eggink http://sudrala.de
Re: add a way to declare global variables
On Dec 12, 4:24 am, Bernd Eggink mono...@sudrala.de wrote:
Am 12.12.2009 02:11, schrieb Matthew Woehlke:
konsolebox wrote:
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.
I thought variables in functions were /always/ global unless declared
local?
It's the other way round. Regarding typeset and declare, the man page
says: When used in a function, makes each name local, as with the
local command. So within a function, typeset, declare, and local are
synonyms. Using 'local' outside a function is an error, so IMHO this
command is completely redundant. It _would_ make some sense, however, if
its counterpart 'global' existed, as it could help clarify the intended
usage of the variable.
Bernd
--
Bernd Egginkhttp://sudrala.de
$ vars () { var1=123; local var2=456; }
$ vars
$ echo var1=$var1 var2=$var2
var1=123 var2=
How is that the other way around?
Re: output redirection with process substitution asynchronous?
Hello again,
I have to reply to my own post to correct it:
On Dec 8, 2:00 pm, pjodrr pjo...@gmail.com wrote:
coproc prefix_timestamp
seq 10${COPROC[1]}
eval exec ${COPROC[1]}-
cat ${COPROC[0]}
wait $COPROC_PID
replace this with:
{ coproc prefix_timestamp 3 ; } 31
seq 10${COPROC[1]}
eval exec ${COPROC[1]}-
wait $COPROC_PID
this is how i do it now, thanks for the discussion.
Peter
Re: add a way to declare global variables
2009-12-12, 12:37(-05), Chet Ramey: On 12/12/09 5:24 AM, Bernd Eggink wrote: It's the other way round. Regarding typeset and declare, the man page says: When used in a function, makes each name local, as with the local command. So within a function, typeset, declare, and local are synonyms. Using 'local' outside a function is an error, so IMHO this command is completely redundant. It _would_ make some sense, however, if its counterpart 'global' existed, as it could help clarify the intended usage of the variable. It might be considered redundant, but just consider it a more mnemonic synonym for declare/typeset. `local' appeared in an earlier version of the Posix standard, though `typeset' never did. [...] local is also mandated by the LSB spec for sh as well (Linux standard base). So you can reasonably expect to be able to use it (though only in local varname) on any script meant for a recent Linux sh. -- Stéphane
Re: add a way to declare global variables
On 12/12/09 5:28 AM, Bernd Eggink wrote: Am 10.12.2009 10:40, schrieb konsolebox: 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. I second that. I'm missing this feature badly. Presently, you can only get around this restriction by using a lot of ugly and dangerous 'eval's. OK. I'm interested in use cases for this feature. What are you trying to do that you're missing it badly? 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: add a way to declare global variables
Am 12.12.2009 21:41, schrieb Chet Ramey: On 12/12/09 5:28 AM, Bernd Eggink wrote: Am 10.12.2009 10:40, schrieb konsolebox: 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. I second that. I'm missing this feature badly. Presently, you can only get around this restriction by using a lot of ugly and dangerous 'eval's. OK. I'm interested in use cases for this feature. What are you trying to do that you're missing it badly? One example is introducing some kind of data encapsulation in bash, or even a modest form of object orientation. You may laugh at it, but I think it might be useful in complex scripts. I experimented a little and came up with 'classes' consisting of a function, and 'objects' consisting of a function (representing the interface) plus an equally named associative array (containing the data). The difficulties arise if you want to create an object 'a' of class X by saying X create a You can declare a function 'a' dynamically within function X (using eval), but you can't declare a (global) associative array 'a' there. So that's where a global declaration would be desirable. The alternative is to print the declarations and eval the whole thing in the current environment, but that is very inconvenient and can cause nasty quoting problems. Regards, Bernd -- Bernd Eggink http://sudrala.de
Re: best way to test for empty dir?
On Sat, 12 Dec 2009 10:51:31 +0100 Andreas Schwab sch...@linux-m68k.org wrote: Matias A. Fonzo s...@dragora.org writes: A solution to check the broken symlink is: [ -e foo -o -L foo -a ! -e foo ] In which way is the last check not redundant? In the sense that you have -e to check existing files and non-broken symlinks -instead of- -e -o -L. Regards, Matías
