zsh-workers
 help / color / mirror / code / Atom feed
From: Phil Pennock <comet@fysh.org>
To: zsh-workers@sunsite.auc.dk
Subject: Re: set -A and stat -A vs. typeset -A and stat -H
Date: Thu, 28 Jan 1999 17:50:16 +0000	[thread overview]
Message-ID: <19990128175016.A24442@fysh.org> (raw)
In-Reply-To: <990128093329.ZM1677@candle.brasslantern.com>; from "Bart Schaefer" on Thu 28 Jan 1999 (9:33 -0800)

Typing away merrily, Bart Schaefer produced the immortal words:
> On Jan 28,  1:23pm, Phil Pennock wrote:
> } `stat -A' was already taken.  For assigning to an Array.
> 
> Yes, and is so because of `set -A', I imagine (hence the Subject).  My

Helps to read things properly.  Oops.

> point is not that you should have chosen -A for `stat', but that there
> really isn't *any* option letter that can be the same for all of `set',
> `typeset' and any third command you might name.

I hope that you mean, "you should have been able to choose -A for
`stat'", since it was already taken by whoever implemented that.  I
didn't change it, for compatibility.  But hey, stat's new to 3.1.5
(afaicr) so whatever.

Generally, I have no objections whatsoever to changing the option.  I
was just gratified to see someone modify the examples to make use of my
addition.  A nice warm fuzzy feeling inside... :^)

> }         "What are four lowercase letters that are not legal flag arguments
> } to the Berkeley UNIX version of `ls'?"
> } 
> } HAND (and no, the first two letters of that are just coincidence).
> 
> Um, HAND are not lowercase letters ... and BSD `ls' does use -A. ;->
> (My answer would be e j v y, but I had to think about it for too long.)

I was actually thinking of 'HA' in relation to the stat options.

Erm, Bart, is that the first time that you've used a smiley on the
zsh-workers list?  :^)  *ducks*

Anyway, back on topic.  Given all this overloading in typeset and set,
how feasible is it to do a split-out, similar to the completion stuff
recently?  Ie, carefully examine the functionality requirements, add (I
suspect) three new builtins, organise the options consistenly for those.
Make the set and typeset compatibility interfaces with a couple of other
bits left ('set'ting the argv stuff), and then remove any options that
weren't there in 3.0.x.

Yes, it pollutes the namespace some more.  But how viable is it to
continue the way things are at present, squeezing more and more into a
limited space with consistency conflicts?

(PS: I start shifts soon, and should be able to hack zsh a bit more when
I'm on nights - fear)
-- 
--> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$
L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++
DI+ D+ G+ e+ h* r y?


  parent reply	other threads:[~1999-01-28 17:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-28  9:47 Bart Schaefer
1999-01-28 13:23 ` Phil Pennock
1999-01-28 17:33   ` Bart Schaefer
1999-01-28 17:43     ` Bruce Stephens
1999-01-28 17:50     ` Phil Pennock [this message]
1999-01-30  6:22       ` Bart Schaefer

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=19990128175016.A24442@fysh.org \
    --to=comet@fysh.org \
    --cc=zsh-workers@sunsite.auc.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).