zsh-workers
 help / color / mirror / code / Atom feed
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
________________________________________________________________________


      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).