8 Nov 2007 23:07
8 Nov 2007 23:27
Re: fail to expand/assigned subshell output into a local variable
Oleg Verych <olecom <at> gmail.com>
2007-11-08 22:27:20 GMT
2007-11-08 22:27:20 GMT
== 11/8/07, Mike Frysinger ==
> this code snippet incorrectly
Why incorrectly? There's no assignments in the `local`. It's a built-in,
thus word splitting does its job, and incorrect names, that start with
digits and have other than alpha-numeric symbols, are syntax
errors.
> fails under dash: $ { local f=$(date); } local: 5: 8: bad variable name
____
-
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
9 Nov 2007 00:01
Re: fail to expand/assigned subshell output into a local variable
Oleg Verych <olecom <at> gmail.com>
2007-11-08 23:01:49 GMT
2007-11-08 23:01:49 GMT
== 11/8/07, Oleg Verych ==
> == 11/8/07, Mike Frysinger ==
> > this code snippet incorrectly
>
> Why incorrectly? There's no assignments in the `local`.
... in the man page (and i didn't used that `feature' myself);
> It's a built-in, thus word splitting does its job,
thus, double quotes will prevent this...
> and incorrect names, that start with digits and have other than
> alpha-numeric symbols, are syntax errors.
>
> > fails under dash: $ { local f=$(date); } local: 5: 8: bad variable name
____
-
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
11 Nov 2007 07:18
Re: Here-document...
Herbert Xu <herbert <at> gondor.apana.org.au>
2007-11-11 06:18:37 GMT
2007-11-11 06:18:37 GMT
On Tue, Oct 30, 2007 at 04:23:35AM +0000, Oleg Verych wrote: > > } 8<<"" > ====================== Actually this (the empty delim) only works with dash by accident. I've tried bash and pdksh and they both terminate on the first empty line which is what you would expect rather than EOF. The real Korn shell does something completely different. I've fixed this in dash to conform to bash/pdksh. > In [0] it's stated, that delimiter isn't evaluated (expanded), only > quoiting must be checked. That if() seems to be completely bogus. OK I agree. The reason it was there is because the parser would have already replaced the dollar sign by an internal representation. I've fixed it properly in the patch below. > Placing binary stuff safely with optimized reading/writing by big > blocks without parsing, if delimiter is "", are things, that i'd like > to propose and possibly fix/implement soon. Sorry but I can't see how we can get this to work in a meaningful way. Cheers, -- -- Visit Openswan at http://www.openswan.org/(Continue reading)
11 Nov 2007 07:43
New GIT repository
Herbert Xu <herbert <at> gondor.apana.org.au>
2007-11-11 06:43:59 GMT
2007-11-11 06:43:59 GMT
Hi: Thanks to the kernel.org maintainers the dash repository is now hosted on git.kernel.org. You can get to it via git://git.kernel.org/pub/scm/utils/dash/dash.git or http://www.kernel.org/pub/scm/utils/dash/dash.git It also means that we now have a web interface: http://git.kernel.org/?p=utils/dash/dash.git;a=summary Cheers, -- -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
11 Nov 2007 21:36
Here-document with quoted delimiter.
Oleg Verych <olecom <at> gmail.com>
2007-11-11 20:36:49 GMT
2007-11-11 20:36:49 GMT
== 11/11/07, Herbert Xu == > On Tue, Oct 30, 2007 at 04:23:35AM +0000, Oleg Verych wrote: > > > > } 8<<"" > > ====================== > > Actually this (the empty delim) only works with dash by accident. > I've tried bash and pdksh and they both terminate on the first > empty line which is what you would expect rather than EOF. The > real Korn shell does something completely different. > > I've fixed this in dash to conform to bash/pdksh. [] > > Placing binary stuff safely with optimized reading/writing by big > > blocks without parsing, if delimiter is "", are things, that i'd like > > to propose and possibly fix/implement soon. > > Sorry but I can't see how we can get this to work in a meaningful > way. I hope you know what `makeself` is. There is to much scripting and external tools used to achieve basic thing: to copying binary data after script in the script file to a separate file and to do something with it (mainly gunzip/bunzip + run another script). Also it all is written is quoted form, which is very unreadable and ugly. After making that very simple shell stub (in prev mail), i realized, that things can be done very easily.(Continue reading)
11 Nov 2007 23:59
Features.
Oleg Verych <olecom <at> gmail.com>
2007-11-11 22:59:40 GMT
2007-11-11 22:59:40 GMT
0. Introduce versioning and feature check.
1. Patterns.
1.1 Restore original ash idea about negative pattern matching
(DIFFERENCES .9), but with only one `!', as it can be enables in
bash.
1.2 Make patterns to distinguish files and directories, because
searching algorithm already doing this as result of `*/*'
expansions, for example.
Sometimes it's better to have a list of files only, without
additional `find`. I don't know what syntax to propose,
especially if socket/fifo/devnode matching will be requested
later. Maybe
mplayer &F*/* # play files
cat !&P* # output content of not fifos(pipes)
ls -l /dev/&Dhd* # show a bit more info devnodes /dev/hd*
1.3 To sort output only on request.
I see no value in sorting it.
1.4 To do not output patterns in case of empty match.
Quoting is meant to be done for anything, shell can screw up.
Thus, i also see no value in saving pattern for programs, that
don't expect such ``file names'' anyway.
2. Restore `setvar variable value`. It is better, than to use `eval` to
(Continue reading)
12 Nov 2007 01:09
Re: Features.
H. Peter Anvin <hpa <at> zytor.com>
2007-11-12 00:09:29 GMT
2007-11-12 00:09:29 GMT
Oleg Verych wrote: > > 5.2 IMHO making user accessible file descriptors in range of [3-9] is > kind of silly, when open() returns lowest available fd number, > and shell have no semantics of saying "no, this fd is used already". > > Making them in higher and wider region, say in [100-255] is > quite reasonable. Making them as special variables, like > parameters `$1' are, makes even more sense, thus preventing any > potential problems. > Everyone is using 3-9 though. I would suggest just moving the lower limit higher, e.g. 3-99. -hpa - To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
12 Nov 2007 02:34
Redirections (Re: Features.)
Oleg Verych <olecom <at> gmail.com>
2007-11-12 01:34:55 GMT
2007-11-12 01:34:55 GMT
== 11/12/07, H. Peter Anvin == > Oleg Verych wrote: > > > > 5.2 IMHO making user accessible file descriptors in range of [3-9] is > > kind of silly, when open() returns lowest available fd number, > > and shell have no semantics of saying "no, this fd is used > already". > > > > Making them in higher and wider region, say in [100-255] is > > quite reasonable. Making them as special variables, like > > parameters `$1' are, makes even more sense, thus preventing any > > potential problems. > > > > Everyone is using 3-9 though. I would suggest just moving the lower > limit higher, e.g. 3-99. From the user point of view, keeping track of fds by numbers is very hard. While procfs example may not be correct one, but anyway it shows a bug and some fd manipulation inside of "user range". # echo 7>&2 echo '=echo= ' /proc/$$/fd/* ' =ls=' ls -l /proc/$$/fd/* #(Continue reading)
12 Nov 2007 05:12
Re: Redirections (Re: Features.)
Oleg Verych <olecom <at> gmail.com>
2007-11-12 04:12:43 GMT
2007-11-12 04:12:43 GMT
> > > 5.2 IMHO making user accessible file descriptors in range of [3-9] is > > > kind of silly, when open() returns lowest available fd number, > > > and shell have no semantics of saying "no, this fd is used > > already". > > > > > > Making them in higher and wider region, say in [100-255] is > > > quite reasonable. Making them as special variables, like > > > parameters `$1' are, makes even more sense, thus preventing any > > > potential problems. > > > > > > > Everyone is using 3-9 though. I would suggest just moving the lower > > limit higher, e.g. 3-99. I don't know how heavily system() is used. Based on my shell scripting experience in Debian, i'd say not that much. And i doubt program(er)s care about having their opened fds above suggested by POSIX number 9 before system(). Of course shell will be blamed, if something non trivial, e.g. opening and manipulating of FDs other than STDIO[0-2], is being ran. Realizing this now, i understand why apt-get/C++ and dpkg/C were so unhappy in some places with my scripting (mainly `geloiwa'). ____ - To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html(Continue reading)
RSS Feed