Re: [ast-users] Thank you for the grep builtin!
great - any soft numbers on improvement? On Thu, 6 Jun 2013 11:23:27 +0200 Lionel Cons wrote: > I'd like say "Thank you" for adding the grep builtin to ksh93. > Today we figured out that this gave a major performance boost and > helped a lot working around shoddy or broken grep implementations. > Thank you! > Lionel ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] set -u updates in POSIX.1-2008 TC1
> "exit status of between 1 and 125 inclusive" - doesn't ksh93 return > exit status between 0 and 255? Why are 126 and 127 omitted? They have a special meaning 0: success 126: command cannot be executed 127: command not found I suppose that creating 126 and 127 makes no sense with a built-in. Values >255 can generally also be created to deliver signals. Janis > > Lionel > ___ > ast-users mailing list > ast-users@lists.research.att.com > http://lists.research.att.com/mailman/listinfo/ast-users ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
[ast-users] cd -@ (XATTR) broken in latest ast-ksh alpha?
Is it a know problem that cd -@ (cwd into NFSv4/cifs extended attribute directories) is no longer working in the latest ast-ksh alpha? This happens with ast-ksh.20130524 on Solaris 11.1. Ced -- Cedric Blancher Institute Pasteur ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
[ast-users] VMALLOC_OPTIONS='abort' no longer calling abort() on heap corruption?
A colleague is asking: Is VMALLOC_OPTIONS='abort' no longer calling abort() on heap corruption when libast::free() is passed a pointer which does not originate from libast::malloc()/calloc()? libast version is ast-ksh.2013-05-24 Lionel ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
[ast-users] Thank you for the grep builtin!
I'd like say "Thank you" for adding the grep builtin to ksh93. Today we figured out that this gave a major performance boost and helped a lot working around shoddy or broken grep implementations. Thank you! Lionel ___ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
Re: [ast-users] set -u updates in POSIX.1-2008 TC1
On 5 June 2013 19:46, Nathan Weeks wrote:
> POSIX.1-2008 TC1 changed the behavior of "set -u" to apply to all parameters
> (other than "@" and "*") instead of just variables.
>
> POSIX.1-2008:
>
> -u
> The shell shall write a message to standard error when it tries to
> expand a variable that is not set and immediately exit. An interactive
> shell shall not exit.
>
> POSIX.1-2008 TC1:
>
> -u
> When the shell tries to expand an unset parameter other than the '@'
> and '*' special parameters, it shall write a message to standard error
> and shall not execute the command containing the expansion, but for
> the purposes of setting the '?' special parameter and the exit status
> of the shell the command shall be treated as having been executed and
> returned an exit status of between 1 and 125 inclusive. A
> non-interactive shell shall immediately exit. An interactive shell
> shall not exit.
>
> ksh93 2012-02-29 does not treat, e.g., the expansion of unset positional
> parameters as an error, nor does it issue an error when an unset positional
> parameter is used in a parameter expansion of the form "${#parameter}",
> "${parameter%[word]}", "${parameter%%[word]}", "${parameter#[word]}", or
> "${parameter##[word]}", for which POSIX.1-2008 TC1 states:
>
>If parameter is unset and set -u is in effect, the expansion shall fail.
"exit status of between 1 and 125 inclusive" - doesn't ksh93 return
exit status between 0 and 255? Why are 126 and 127 omitted?
Lionel
___
ast-users mailing list
ast-users@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-users
