Hubert Feyrer | 1 Oct 01:04 2004
Picon

Re: the state of regex(3)

On Thu, 30 Sep 2004, Greywolf wrote:
> ...or Did I Miss Something Here?®

Of course I was not speaking of a NetBSD/(trying to be)POSIX-conformant 
system.

  - Hubert

--

-- 
                          ,,_
If wishes were wings,  o"   )~  would fly.            -- Go www.NetBSD.org!
                         ''''
Greg A. Woods | 1 Oct 20:55 2004
X-Face

Re: the state of regex(3)

[ On Thursday, September 30, 2004 at 23:10:25 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: the state of regex(3)
>
> Indeed. I was heavily grossed out today when I learned what 
> POSIXLY_CORRECT does for getopt(3) (=> "ls /etc/passwd -l" *yuck*).

You should play with a true, plain, Seventh Edition UNIX for a good long
while before you blame POSIX on anything, especially that.

It's all these young GNU whipper-snappers who have messed things up
royally.

(AT&T released the "real" getopt() into the public domain long before
there was ever any kind of free unix-like OS for a very good reason --
sadly it was, for the most part, ignored.)

--

-- 
						Greg A. Woods
						Planix, Inc.

<woods <at> planix.com>     +1 416 489-5852 x122     http://www.planix.com/

Bruce Korb | 1 Oct 21:29 2004

Re: the state of regex(3)

"Greg A. Woods" wrote:
> > Indeed. I was heavily grossed out today when I learned what
> > POSIXLY_CORRECT does for getopt(3) (=> "ls /etc/passwd -l" *yuck*).
> 
> You should play with a true, plain, Seventh Edition UNIX for a good long
> while before you blame POSIX on anything, especially that.
> 
> It's all these young GNU whipper-snappers who have messed things up
> royally.

Before you start flinging too-short-in-the-tooth epithets, remember,
please, the genesis of the problem:

  sort fumble -o stumble

et al.  Such requirements made the use of the getopt() function
difficult/impossible.  So, to enable utilities that allowed misordered
options to use getopt(), getopt() was "enhanced" to make that
sort invocation look like:

  sort -o stumble fumble

to the utility.  "ls(1)" went along for the ride.  Now, we have to suffer
long-winded arguments over whether or not GNU prior art should count in the
grand scheme of portable interfaces and what happens when you have
portably named files with names that begin with a hyphen.  Yum, yum.
Well, we're here now and like it or not if you write a script (er,
"application") that might stumble into files named, "-l", then you
had best protect the name by using either "./-l" or "-- -l" on the
command line.
(Continue reading)

David Laight | 1 Oct 22:17 2004
Picon

Re: the state of regex(3)

> I have ALWAYS assumed that the first non-option(-associated) parameter
> terminated option processing.  I was really surprised to discover, five
> minutes ago, that Linux treats 'ls /etc/passwd -l' as 'ls -l /etc/passwd'.
> That HEAVILY violates the POLA.

yes - I found that one while writing some code to run under cygwin.

It can also be avoided by starting the option string with '+'.
(I'm not sure how that affects starting the string with ':', or the
ability to use '+' as an option character!)

FWIW 'rlogin host -l username' has always worked.

	David

--

-- 
David Laight: david <at> l8s.co.uk

David Young | 1 Oct 23:38 2004
Picon

send your use-cases for makefs -t cd9660 !

I am mentoring a senior project group at UIUC.edu that is programming a
'cd9660' target for makefs(8).  I have described for them one use-case,
which is privilegelessly building a bootable, "live" CD-ROM image
for x86.  If you have additional use-cases, won't you send them to me?
Use-cases that are very obvious to you, I have probably not thought of.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Bill Studenmund | 1 Oct 23:46 2004
Picon

Re: UTF-8 file names?

On Thu, Sep 30, 2004 at 09:34:51AM +0000, Valeriy E. Ushakov wrote:
> Thomas Klausner <wiz <at> netbsd.org> wrote:
> 
> >> Note that this patch doesn't handle -B and -b options, because I'm
> >> not sure how strvis() should be i18n'ized.
> > 
> > Does someone else have comments on this?
> 
> What about
> 
> \xHHHH or for double byte encodings
> \uHHHH or \UHHHHHHHH for unicode (or whatever java and c99 syntax is).

I'm confused as to why we would want both. Is there prior art we're 
following?

I ask as my initial read on your comments is that one syntax would 
generate UTF-16 output, and the other would generate UTF-8. However it 
strikes me that we either are dealing with a routine that works with only 
one or the other (it is passed wchar or char strings explicitly) or we are 
dealing with an output routine that learns what to do based on ENV 
settings. In either case, there is enough context that I don't see why 
we'd need both.

Take care,

Bill
Hubert Feyrer | 2 Oct 00:03 2004
Picon

Re: send your use-cases for makefs -t cd9660 !

On Fri, 1 Oct 2004, David Young wrote:
> I am mentoring a senior project group at UIUC.edu that is programming a
> 'cd9660' target for makefs(8).  I have described for them one use-case,
> which is privilegelessly building a bootable, "live" CD-ROM image
> for x86.  If you have additional use-cases, won't you send them to me?
> Use-cases that are very obvious to you, I have probably not thought of.

  * Install CDs, which may have
     + a kernel either inside a floppy-image (similar to what you set with
       mkisofs -b), or
     + just a loader (grub's iso9660_stage1_5 / stage2_eltorito) which
       will then pull a kernel from the CD (the 2.0 Live CD has/does that)
    The install kernel usually has a RAMdisk (md) with the most needed
    files (sysinst, ...), but would mount the CDROM for install files
  * A live CD that boots the kernel in either of two ways (as above),
    but that immediately mounts the kernel (config: root on cd0a or hd0?),
    and the starts things immediately? (The 2.0 Live CD documentation
    has a funny example of a mkisofs call for that, spanning over almost
    ten lines :)
  * Non-PC boot support would be VERY nice - MacPPC, sparc, sparc64,
    vax, ...; this may involve some nasty checksum tweaking (see
    src/distrib/cdrom and src/distrib/utils/sparkcrc)
  * A multi-arch CD to allow one CD to boot on several
    machines, and then pick the right loader/kernel/root-filesystem
    to start, before possibly mounting more filesystems (like install
    sets, which may be shared); again, see src/distrib/cdrom
  * Use as a tool to hook into src/distrib/cdrom and/or the release
    creation process to automatically spit out install CDs.
    Adding files like binary packages would be a big bonus!

(Continue reading)

Greg A. Woods | 2 Oct 00:05 2004
X-Face

Re: the state of getopt(3)...

[ On Friday, October 1, 2004 at 12:29:18 (-0700), Bruce Korb wrote: ]
> Subject: Re: the state of regex(3)
>
> Before you start flinging too-short-in-the-tooth epithets, remember,
> please, the genesis of the problem:
> 
>   sort fumble -o stumble
> 
> et al.

That's _not_ the problem -- that's the _solution_!  :-)

>  Such requirements made the use of the getopt() function
> difficult/impossible.

Well, yeah.

The "--" option is a good idea, but for those who really do like mixing
option flags and parameters it could be said that it wasn't taken far
enough in terms of how getopt() actually works.

>  So, to enable utilities that allowed misordered
> options to use getopt(), getopt() was "enhanced" to make that
> sort invocation look like:
> 
>   sort -o stumble fumble
> 
> to the utility.

That's not getopt() that was enhanced -- it was more "de-enhanced".  :-)
(Continue reading)

Greywolf | 2 Oct 00:15 2004

Re: the state of regex(3)

[Thus spake David Laight ("DL: ") 9:17pm...]

DL: yes - I found that one while writing some code to run under cygwin.
DL:
DL: It can also be avoided by starting the option string with '+'.
DL: (I'm not sure how that affects starting the string with ':', or the
DL: ability to use '+' as an option character!)
DL:
DL: FWIW 'rlogin host -l username' has always worked.

That has also always been documented, and was implemented as such
so that one could symlink /usr/bin/rlogin to /usr/hosts/host,
and then just run

	host -l username ...

[as it compared the basename of argv[0] to "rlogin".  Hope you don't
have a host named "rlogin"...]

DL: 	David
DL:
DL: --
DL: David Laight: david <at> l8s.co.uk

There are obviously exceptions to the rule, but those are usually well
known, especially once one discovers that the command does not follow
the "standard".

I am still not amused by getopt()'s behaviour under Linux.

(Continue reading)

Bruce Korb | 2 Oct 00:32 2004

Re: the state of getopt(3)...

"Greg A. Woods" wrote:

> >   sort fumble -o stumble
> >
> > et al.
> 
> That's _not_ the problem -- that's the _solution_!  :-)

??  :-}

> >  Such requirements made the use of the getopt() function
> > difficult/impossible.
> 
> Well, yeah.
> 
> The "--" option is a good idea, but for those who really do like mixing
> option flags and parameters it could be said that it wasn't taken far
> enough in terms of how getopt() actually works.

Personally, I'd as soon see misordered options banned,
but despite my opinion on that, there really is a critical
mass of GNU-ish coders out there who like the idea.  Consequently,
I allowed myself to be prodded into ``reorder-args''

  http://autogen.sourceforge.net/doc/autogen_191.html#SEC191

in my option processing toy.

> That's not getopt() that was enhanced -- it was more "de-enhanced".  :-)

(Continue reading)


Gmane