Re: More fun with IFS
Dan Douglas dixit: For $@ that sounds about right. I think it would be preferable if x=$@ and x=$@ were the same. If a user wants IFS-delimited they should probably use Hrm, but the docs, both, specifically say that (unquoted) $@ behaves like $* except in the face of no arguments, so I cannot do that. But thanks for the feedback. My reading differed, but you have a point, and the others can be kept as-is. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: More fun with IFS
On Friday, March 01, 2013 01:06:27 PM Thorsten Glaser wrote: Hrm, but the docs, both, specifically say that (unquoted) $@ behaves like $* except in the face of no arguments, so I cannot do that. But thanks for the feedback. My reading differed, but you have a point, and the others can be kept as-is. I think the root of the problem is trying to force unquoted $@ to be like $* instead of the other way around. That's how bash (if not for the bug) and ksh93 manage to do this while remaining consistent with the spec. -- Dan Douglas
Re: export in posix mode
On 2/27/13 5:42 PM, Bob Proulx wrote:
Chet Ramey wrote:
I don't know what version you're using; I have 0.11.
$ ./posh
\[\]${HOST}($SHLVL)\$ exit 1
./posh: exit: bad number
$ ./posh
\[\]${HOST}($SHLVL)\$ exit 10
./posh: exit: bad number
$ echo $?
1
I am using 0.11 too. I was using the Debian packaged version. Since
this originated with Debian it is packaged using native packaging
where the tar.gz file is used without any patches to an upstream since
upstream is Debian. That means 0.11 without a 0.11-number -number on
the end.
I just now pulled the source code and did a build and the locally
compiled copy worked fine.
I can only assume this is some type of portability bug in the sources
compiled on your system. I can't imagine that many people compile
that program on other systems. It can't have gotten that much
exposure.
I built it on Mac OS X with a couple of portability problems (undeclared
functions, assuming pointers and ints are the same size, etc.). It's
probably another one of those. If I get inspired I may try to track it
down.
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/
Leveraging the completion system to discover available options in a command
Hi, Is it possible to use the completion system to get a list of available options for a command bash knows how to auto-complete? Ideally, I'd like given the name of a program to get a list of pairs (option string, desc) for each available option. I'd be nice to also get options that are only available in a specific context, but given how the completion system works, I'd guess that that might be impossible.
Re: Should this be this way?
Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Supposedly this has to do with memory corruption problems in 4.2 and the possibility that it might come back... Is this likely to be a problem? Dr. Werner Fink wrote: The patch belongs to memory corruption ahd happen with several bug reports like: http://bugzilla.novell.com/show_bug.cgi?id=382214 http://bugzilla.novell.com/show_bug.cgi?id=384175 that is that after the siglongjmp() the bash had showed memory corruption. This seems to be fixed in bash 4.2 ... nevertheless it could come back again as memory management together with setjmp()/longjmp() or sigsetjmp()/siglongjmp() has to managed thorough to not run into the same problems as in the bugs above. This is the only reason why this patch is still alive. And yes I've read the thread http://www.mail-archive.com/bug-bash@gnu.org/msg12269.html
Re: Should this be this way?
On 3/1/13 5:04 PM, Linda Walsh wrote: Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Supposedly this has to do with memory corruption problems in 4.2 and the possibility that it might come back... I think you mean bash-3.2. The bug report is five years old. It sounds like the SuSE change might be there for quite a while, because, even though it's fixed, the problem could always come back. I do wonder why only SuSE exhibits the problem. 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/
