From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: PATCH: access to names of errors
Date: Tue, 22 Jul 2003 17:51:47 +0200 [thread overview]
Message-ID: <1362.1058889107@gmcs3.local> (raw)
In-Reply-To: <22303.1058880773@csr.com>
Peter wrote:
> This patches the parameter module to add $sys_errnos, which turns $ERRNO
> into the name of the error --- not the error text you would get with
> strerror(), the standard name. This is more useful for programming,
> since if you know you can test for
>
> [[ $sys_errnos[$ERRNO] = EINTR ]]
>
> and so on. It's also more difficult, but I simply copied the code for
> signal names.
>
> I'd appreciate comments on
> - where this should appear; I'm planning on an interface to the system
> read function and it could go there instead. This might be
> better since the parameter module usually provides shell rather
> than system information and the new array bloats it somewhat.
> The new module could be a generic zsystem module.
I'd say it shouldn't be in the parameter module because as you say, that
interfaces to shell rather than system information. I'd just call the
module `system'. The `z' seems a bit redundant especially as it is
effectively zsh/system with the namespace.
> - what it should be called; the current name at least paves the way
> for a move into a different namespace such as $sys.errnos, should
> anybody ever have the time to rewrite the parameter code completely
I'd have thought just $errnos would be fine. Especially if it can be in
a system namespace in the long term.
> - what else we should provide; strerror() would be fairly easy, but
> an array would probably have to be generated specially during
> configuration, because the internal system array seems to be
> non-standard. We can check for _sys_errlist and _sys_nerr first,
> perhaps.
By during configuration, do you mean by autoconf? When the module is
loaded would be better. If it's in an out of the way module that isn't
loaded by default, I don't think it matters. That long over due parameter
code rewrite will have to allow individual array elements to be generated
on demand.
Oliver
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
prev parent reply other threads:[~2003-07-22 15:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 13:32 Peter Stephenson
2003-07-22 15:51 ` Oliver Kiddle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1362.1058889107@gmcs3.local \
--to=okiddle@yahoo.co.uk \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).