Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Julian Elischer]

Hellmuth Michaelis wrote:
> 
> >From the keyboard of Juergen Lock:
> 
> >  And the other reason i'm looking at ijppp is ppp compression.  It
> > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > should at least help if the other end is running bsd or linux,
> > but if your other end is something like an ascend or an external
> > router (zyxel, cisco(?), there are probably more that speak this
> > protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
> > even you'd want M$' special version of that (yes of course they
> > invented their own `standard' again.)  So my question is, is
> > anyone working on this?  There is (alpha) code that does this on
> > linux,
> >
> >   http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
> 
> I've looked at that. Its very Linux-centric and i gave up for the moment
> when i realized how much work it would be to port it.
> 
> Brian's ppp over i4b does support deflate compression and i get very
> good results out of it - too good to put more work into the above URL.
> 
> > today...  impressive stuff.)  and is someone working on linking i4b
> > and netgraph?
> 
> There will be a netgraph node interface which will link an i4b B-channel
> to netgraph. There are no plans from my side to netgraphify the D-channel
> part of i4b.

to add a negraph interface to the B channels should be quite easy.
If you need help I can prbably almost do most of it..

(I did look at it already some time ago)

when this is done the netgraph PPP nodes (which can support
 these compression types will be usable.



-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
---> X_.---._/  presently in:  Perth
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Copy-on-write filesystem

[sthaug]

> > Imagine: cp file file2, file and file2 reference the same exact blocks,
> > but modified chunks of file2 would be given their own private blocks.
> 
> This is not a microsoft innovation, actually, I believe it was a VMS
> innovation.  It's called a generational filesystem.  the original is
> stored, and later generations of the file are stored as diffs.

As far as I know, VMS simply stores whole files - no diffs involved. Now
if you go back to for instance Univac 1100 and the Exec-8 OS (I suppose
it is OS-1100 now), you'll find a system that *did* store the diffs. In
the form of punched card images! :-)

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Hellmuth Michaelis]

>From the keyboard of Julian Elischer:

> > > today...  impressive stuff.)  and is someone working on linking i4b
> > > and netgraph?
> > 
> > There will be a netgraph node interface which will link an i4b B-channel
> > to netgraph. There are no plans from my side to netgraphify the D-channel
> > part of i4b.
> 
> to add a negraph interface to the B channels should be quite easy.
> If you need help I can prbably almost do most of it..

Its already in the development sources (Archie had a look at it already)
and it works with mppd. It was really quite easy, although if Archies 
daemonnews article had been available at that time i wrote it, it would
have been even easier :-)

> when this is done the netgraph PPP nodes (which can support
>  these compression types will be usable.

In the mppd i worked with (looking ... mpd3.0b1/mpd3.0b2) deflate was not
present, predictor was not usable, bsd was not present. There were just
hooks for M$ and stac (which you can not release obviously).

Currently i'm using ppp instead of mppd mostly just because it supports
deflate compression. I had a look at both mppd and ppp to see how the
mentioned free stac compression would be integrateable and found them
both similar, given they both come from iijppp. It looks like if it were
a good idea if Brian and Archie would merge both to get the best features
from each one into a common product ;-)

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Onstream?

[Soren Schmidt]

It seems Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Matthew 
>Jacob writes:
> : I gave up on supporting it- too much work for too little gain, IMO.
> 
> The same thing happened on the IDE side of things.  Even with Soren's
> hacks, I never could get it to work well.  It worked as well as one
> would expect a win-tape drive to work :-<.
> 
> I have one of these beasts if someone wants it.  I got it from the
> onstream folks (they have an office here in Longmont).  I tried to
> help Soren out, but my tolerence for working in the project was
> extremely low.

That drive is a joke, I'd never recommend it for data you care for..

However I still have it on my TODO list, it just keeps getting
pushed further and further down on it...

The ATAPI version is somewhat supported, ie you can access it, but 
there are no filemarks (the drive doesn't support that) and there 
is no handling of media errors (the drive doesn't support that either).
Other than that it can be used :)

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Brian Somers]

[.]
> Currently i'm using ppp instead of mppd mostly just because it supports
> deflate compression. I had a look at both mppd and ppp to see how the
> mentioned free stac compression would be integrateable and found them
> both similar, given they both come from iijppp. It looks like if it were
> a good idea if Brian and Archie would merge both to get the best features
> from each one into a common product ;-)

The reason we haven't done this yet is my fault.  I've been too busy 
with other things :-/  I hope this'll change soon.

> hellmuth
> -- 
> Hellmuth MichaelisTel   +49 40 55 97 47-70
> HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
> Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
> D-22457 Hamburg   WWW   http://www.hcs.de

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Onstream?

[Christian Weisgerber]

Alan Batie <[EMAIL PROTECTED]> wrote:

> I just got an onstream scsi tape drive only to discover that I should've
> checked the archives because it don't work.

Depends on the drive. If you got an Echo drive (SCxx), you're right.
The ADR drives--yes, they all use ADR tape technology, but confusingly
there's also a model line called "ADR"--on the other hand, are
ordinary SCSI drives, according to the OnStream representative I
talked to at CeBIT. For instance, they're certified to work with
the plain Linux SCSI tape driver.

A few days ago I asked whether anybody's running an ADR50 successfully
off a FreeBSD box but received no response. Actually I'm not sure
the ADR50 is in the stores yet.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Copy-on-write filesystem

[Louis A. Mamakos]

> > > Imagine: cp file file2, file and file2 reference the same exact blocks,
> > > but modified chunks of file2 would be given their own private blocks.
> > 
> > This is not a microsoft innovation, actually, I believe it was a VMS
> > innovation.  It's called a generational filesystem.  the original is
> > stored, and later generations of the file are stored as diffs.
> 
> As far as I know, VMS simply stores whole files - no diffs involved. Now
> if you go back to for instance Univac 1100 and the Exec-8 OS (I suppose
> it is OS-1100 now), you'll find a system that *did* store the diffs. In
> the form of punched card images! :-)

Well, not really.  That was mostly an application convention rather than
being done in the OS.  And that all the applications wanted to use
SIR$ SDF to read program file elements was just a coincidence :-)

The cools part of Exec-8 that we still need (we already have sparse
files) are the virtual filesystem bits.  E.g., unloaded files.  People
have been struggling with multi-level storage architectures on UNIX
for years, while this was pretty much a solved problem on these 1's
complement 36 bit dinosars 30 years ago.  

(The notion was that if you didn't use a file in a while, the system
would release the data blocks, and mark the file as "unloaded."  When
you "assigned"/opened one of these files, a system process would cause
the current backup tape to be loaded, and the file restore.  When you
began to get low on disk space, likeway a systen process would start,
and sort all files based on their priority for being unloaded - based
on last reference time, do we have a current backup, who created it, etc.
It would then begin to release the data blocks until you acheived a
configured threshold.)

louie





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[W Gerald Hicks]

> > bash and ksh complain about unexpected ';'.
> > /bin/sh (FreeBSD) thinks it's ok and does nothing.
> > Which behaviour is more POSIXly correct?

> 
> Neither bash nor ksh claim to be particularly POSIX compliant.  our
> /bin/sh does.  I seem to remember POSIX being ambiguous on this one, but
> my books are at the office.  If you haven't gotten a more conclusive
> answer by Monday, mail me and I'll look it up.

I much prefer the current behavior and believe there may be many things
which depend on it.

Cheers,

Jerry Hicks
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Juergen Lock]

On Sun, Mar 05, 2000 at 06:32:45AM +0100, Hellmuth Michaelis wrote:
> >From the keyboard of Juergen Lock:
> 
> >  And the other reason i'm looking at ijppp is ppp compression.  It
> > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > should at least help if the other end is running bsd or linux,
> > but if your other end is something like an ascend or an external
> > router (zyxel, cisco(?), there are probably more that speak this
> > protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
> > even you'd want M$' special version of that (yes of course they
> > invented their own `standard' again.)  So my question is, is
> > anyone working on this?  There is (alpha) code that does this on
> > linux,
> > 
> > http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
> 
> I've looked at that. Its very Linux-centric and i gave up for the moment
> when i realized how much work it would be to port it.
> 
> Brian's ppp over i4b does support deflate compression and i get very
> good results out of it - too good to put more work into the above URL.
> 
I don't see anything wrong with deflate itself either, its just that
when you don't have control over whats at the other end of the link
its most of the time useless, most equipment thats out there _if_
it does compression at all still only knows the other protocols. :(

> > that seems to be the logical way to do more complex
> > stuff like this aodi thing that e.g. the german Telekom wants to use
> > for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to
> > introduce around the end of the year.  (and _if_ this really works it
> > sure will become pretty popular over here as long as all the other `real'
> > flatrates are still in the 100 DEM or more range... :/ )  this seems to
> > be the current draft:
> 
> - this "flatrate" will only be available to T-Online customers. Since i'm
>   not such a beast and will probably never become one its of not much use
>   for me.
> 
 well for someone who _could_ use it the 8 DEM more (is it still
8?) for the t-offline account may still be worth it, and i don't
think they would even be allowed to force you to do _all_ your ip
over their system...  (yes that may need some routing tweaks but
so be it. :)  at least the proposed aodi protocol shouldn't be in
the way and i've already had two connections open with i4b at the
same time over a single card and it worked as expected.  the only
problem would be you couldn't dynamically up the bandwith of
connections that are already open over the slow link without routing
that additional B channel over t-offline too.  well unless you
start playing with tunnels...)

> - my usage of the internet is not much compatible with what this "flatrate"
>   offers.
> 
 hmm imho there's a lot of things a low-bandwidth link can be useful
for when all your other links are still metered... :/  think of
always getting mail delivered near-immediately at no extra cost
as soon as the box is up, or that you'd no longer have to close and
re-open things like ssh sessions all the time, or that you could
just talk(1) to someone instead of having to pay for a phonecall...
(in case anyone wonders: yes those are also still _always_ metered
here)  and that even while both B channels may be busy with other
things.

 Oh and you could then also get at the box from `anywhere' if you
need to, whithout having to make (and pay for) a direct isdn
connection or other special precautions cause you'd no longer have
to worry about portscanning/flood-pinging script kiddies or other
kinds of `accidents' causing insane phone bills when you leave the
box online while you can't watch it.  (well, assuming you made a
decent firewall.)

 (of course when i look at _my_ usage of the net a 100 DEM 64kbit
flatrate will probably still be more economical (*sigh*), but i
suspect there are lots of people where this wouldn't be so.)

> - the Telecom does not give away anything for free. Check when, why and
>   most important how you are using the internet: the savings you get using
>   this "flatrate" does not pay even a fraction of the time and work needed
>   to implement this - in my eyes.
> 
 Well yes someone would have to do the work and it probably won't
exactly make him rich either, thats true. :)  (but it could make
bsd more popular if it gets this before linux...)

 Regards,
-- 
Juergen Lock <[EMAIL PROTECTED]>
(remove dot foo from address to reply)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)

[Juergen Lock]

On Sun, Mar 05, 2000 at 12:31:30AM -0800, Julian Elischer wrote:
> Hellmuth Michaelis wrote:
> > 
> > >From the keyboard of Juergen Lock:
> > 
> > >  And the other reason i'm looking at ijppp is ppp compression.  It
> > > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > > should at least help if the other end is running bsd or linux,
> > > but if your other end is something like an ascend or an external
> > > router (zyxel, cisco(?), there are probably more that speak this
> > > protocol), you'd want stac lzs (rfc1974), or if its a wintendo box
> > > even you'd want M$' special version of that (yes of course they
> > > invented their own `standard' again.)  So my question is, is
> > > anyone working on this?  There is (alpha) code that does this on
> > > linux,
> > >
> > >   http://www.ibh-dd.de/~beck/stuff/lzs4i4l/
> > 
> > I've looked at that. Its very Linux-centric and i gave up for the moment
> > when i realized how much work it would be to port it.
> > 
> > Brian's ppp over i4b does support deflate compression and i get very
> > good results out of it - too good to put more work into the above URL.
> > 
> > > today...  impressive stuff.)  and is someone working on linking i4b
> > > and netgraph?
> > 
> > There will be a netgraph node interface which will link an i4b B-channel
> > to netgraph. There are no plans from my side to netgraphify the D-channel
> > part of i4b.
> 
> to add a negraph interface to the B channels should be quite easy.
> If you need help I can prbably almost do most of it..
> 
> (I did look at it already some time ago)
> 
> when this is done the netgraph PPP nodes (which can support
>  these compression types will be usable.

They could, but they don't yet, right? :)

 Maybe it still should be added to ijppp first cause debugging user
processes is easier than the kernel...  and at the usual isdn bri
speeds a user process should still be pretty fast enough.

 Regards,
-- 
Juergen Lock <[EMAIL PROTECTED]>
(remove dot foo from address to reply)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Doug Barton]

W Gerald Hicks wrote:
> 
> > > bash and ksh complain about unexpected ';'.
> > > /bin/sh (FreeBSD) thinks it's ok and does nothing.
> > > Which behaviour is more POSIXly correct?
> 
> >
> > Neither bash nor ksh claim to be particularly POSIX compliant.  our
> > /bin/sh does.  I seem to remember POSIX being ambiguous on this one, but
> > my books are at the office.  If you haven't gotten a more conclusive
> > answer by Monday, mail me and I'll look it up.
> 
> I much prefer the current behavior and believe there may be many things
> which depend on it.

Given that Bash in both standard and POSIX mode complains about 'for i
in ; do echo $i; done', I would say that it's not POSIX compatible. What
could/does depend on this behavior "working?"

Doug
-- 
"Welcome to the desert of the real." 

- Laurence Fishburne as Morpheus, "The Matrix"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Removing zombie kernel threads

[Zhihui Zhang]

I have created several kernel threads that can die after being idle for a
while. I did this by copying the kthread_create() funtion from CURRENT
over to FreeBSD 3.3-Release. Is there a way to remove the zombie threads
after they die or prevent them from creating? Any potential problems in
trying to do this?

Any help is appreciated.

-Zhihui



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Onstream?

[Matthew Jacob]

You see- this why I dropped the notion of supporting the earlier unit- if
there's one with a real SCSI i/f, why bother? I mean, yes,  it'll cost more,
but my take on that is "Don't get cheap on your backups".


On 5 Mar 2000, Christian Weisgerber wrote:

> Alan Batie <[EMAIL PROTECTED]> wrote:
> 
> > I just got an onstream scsi tape drive only to discover that I should've
> > checked the archives because it don't work.
> 
> Depends on the drive. If you got an Echo drive (SCxx), you're right.
> The ADR drives--yes, they all use ADR tape technology, but confusingly
> there's also a model line called "ADR"--on the other hand, are
> ordinary SCSI drives, according to the OnStream representative I
> talked to at CeBIT. For instance, they're certified to work with
> the plain Linux SCSI tape driver.
> 
> A few days ago I asked whether anybody's running an ADR50 successfully
> off a FreeBSD box but received no response. Actually I'm not sure
> the ADR50 is in the stores yet.
> 
> -- 
> Christian "naddy" Weisgerber  [EMAIL PROTECTED]
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

vmpfw, again...

[David E. Cross]

I have 2 cores from machines in the aforementioned state.  What should I do?

For those not playing at home, it appears there is some sort of deadlock
situation in the NFS or VM system.  The indication of this is a process that
blocks in 'vmpfw' for no apparent reason.  All other transactions to that
same filesystem continue per normal.  A specific interaction to that same file
will block.  For example say that 'emacs' has entered the 'vmpfw' state,
other transactions to the same FS will continue unimpeded, but
'cat emacs >/dev/null' will also enter eternal disk-wait without ever any
kernel messages.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Keeping using locally modified source

[John Polstra]

In article <[EMAIL PROTECTED]>,
Bill Fenner  <[EMAIL PROTECTED]> wrote:
> 
> I've got this program in my head that takes a CVS tree and turns it
> into a branch ofanother CVS tree (e.g. FreeBSD rev 1.7 turns into
> rev 1.1.1.7) but it's never managed to make it out of my head, so
> it must be harder than I keep thinking it is =)

I've had the same idea for CVSup for quite awhile but haven't gotten
around to implementing it.  It would be a new "import mode" where
the updates you fetched were "imported" onto the vendor branch of
your local repository.  It would be great for maintaining local
modifications.  I've been thinking about it for a long time and
haven't found a reason yet why it wouldn't work.

John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[John Polstra]

In article <[EMAIL PROTECTED]>,
Doug Barton  <[EMAIL PROTECTED]> wrote:
> 
>   Given that Bash in both standard and POSIX mode complains about 'for i
> in ; do echo $i; done', I would say that it's not POSIX compatible. What
> could/does depend on this behavior "working?"

It works for the realistic cases that might actually be useful.  E.g.,:

x=
for i in $x; do
echo $i
done

works fine.  I don't think it matters very much that the pathological
case "for i in ; ..." doesn't work.

John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Doug Barton]

John Polstra wrote:
> 
> In article <[EMAIL PROTECTED]>,
> Doug Barton  <[EMAIL PROTECTED]> wrote:
> >
> >   Given that Bash in both standard and POSIX mode complains about 'for i
> > in ; do echo $i; done', I would say that it's not POSIX compatible. What
> > could/does depend on this behavior "working?"
> 
> It works for the realistic cases that might actually be useful.  E.g.,:
> 
> x=
> for i in $x; do
> echo $i
> done
> 
> works fine.  I don't think it matters very much that the pathological
> case "for i in ; ..." doesn't work.

Agreed on all counts. By "this behavior" I was referring to the
example.

Doug
-- 
"Welcome to the desert of the real." 

- Laurence Fishburne as Morpheus, "The Matrix"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[W Gerald Hicks]

From: Doug Barton <[EMAIL PROTECTED]>
Subject: Re: empty lists in for
Date: Sun, 05 Mar 2000 11:39:49 -0800

> W Gerald Hicks wrote:
> > 
> > > > bash and ksh complain about unexpected ';'.
> > > > /bin/sh (FreeBSD) thinks it's ok and does nothing.
> > > > Which behaviour is more POSIXly correct?
> > 
> > >
> > > Neither bash nor ksh claim to be particularly POSIX compliant.  our
> > > /bin/sh does.  I seem to remember POSIX being ambiguous on this one, but
> > > my books are at the office.  If you haven't gotten a more conclusive
> > > answer by Monday, mail me and I'll look it up.
> > 
> > I much prefer the current behavior and believe there may be many things
> > which depend on it.
> 
>   Given that Bash in both standard and POSIX mode complains about 'for i
> in ; do echo $i; done', I would say that it's not POSIX compatible. What
> could/does depend on this behavior "working?"
> 

Even though it's my preferred shell, I certainly wouldn't say
that Bash is any sort of standard, certainly not in the POSIX
sense.

Imagine processing a possibly empty list constructed from a
'make' expansion...  Without this behavior one would have to
code a guard of some sort around the 'for' construct.

If everything is checked through make release, I would hold
little objection to a change *after* 4.0-RELEASE.

That includes all conditional paths through make release ...

--

Jerry Hicks
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[John Polstra]

Doug Barton wrote:
> 
>   Agreed on all counts. By "this behavior" I was referring to the
> example.

Yep -- I was agreeing with you. :-)

John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Doug Barton]

W Gerald Hicks wrote:

> Even though it's my preferred shell, I certainly wouldn't say
> that Bash is any sort of standard, certainly not in the POSIX
> sense.

Well, one of Chet's stated goals is to be as POSIX as possible. I agree
that letting the standard speak for itself is a better idea, I was just
giving a perspective. 
 
> Imagine processing a possibly empty list constructed from a
> 'make' expansion...  Without this behavior one would have to
> code a guard of some sort around the 'for' construct.

John Polstra already pointed this out, and Bash handles this like you
would expect. There is a difference between expanding an empty list and
trying to expand a list that isn't there. 
 
Doug
-- 
"Welcome to the desert of the real." 

- Laurence Fishburne as Morpheus, "The Matrix"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[W Gerald Hicks]

From: Doug Barton <[EMAIL PROTECTED]>

>   John Polstra already pointed this out, and Bash handles this like you
> would expect. There is a difference between expanding an empty list and
> trying to expand a list that isn't there. 

Convince me that nothing like the following exists in the
ports framework and /usr/src and I'd be ok with a change
*after* 4.0 release (repeats himself)

# Makefile.foo

FOOVAR=

  .
  .
  .

BARVAR=${FOOVAR}

baz:
 for i in ${BARVAR} ; do \
 ${BLAP} $$i ; \
 done


To me, changing it right now on the eve of -release
would be gratuitous. Later I would be fine with it.

I still prefer /bin/sh being able to handle an empty
literal list but would yield to the desires of others.

--
Jerry Hicks
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Doug Barton]

W Gerald Hicks wrote:

> To me, changing it right now on the eve of -release
> would be gratuitous. Later I would be fine with it.
> 
> I still prefer /bin/sh being able to handle an empty
> literal list but would yield to the desires of others.

I think you misunderstand me. I'm not suggesting any changes, unless
the fact that our /bin/sh DOES handle the non-existent list case breaks
something. My feeling in general is that the more POSIX compliant we are
the better, but I don't really know what the standard says about this. 

Doug
-- 
"Welcome to the desert of the real." 

- Laurence Fishburne as Morpheus, "The Matrix"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Chris Costello]

On Saturday, March 04, 2000, Sheldon Hearn wrote:
> Neither bash nor ksh claim to be particularly POSIX compliant.  our
> /bin/sh does.

   ksh doesn't claim to be POSIX compliant?

"ksh is intended to conform to the Shell Language Standard
 developed by the IEEE POSIX 1003.2 Shell and Utilities Language
 Committee."
   -- http://www.kornshell.com/info/

   And on a FreeBSD-compiled binary of the real AT&T ksh code:

 $ echo ${.sh.version}
 Version M 1993-12-28 i
 $ for i in ; do echo $i; done
 $ 

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Breakthrough: It nearly booted on the first try.
`


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: empty lists in for

[Martin Cracauer]

In <[EMAIL PROTECTED]>, John Polstra wrote: 
> In article <[EMAIL PROTECTED]>,
> Doug Barton  <[EMAIL PROTECTED]> wrote:
> > 
> > Given that Bash in both standard and POSIX mode complains about 'for i
> > in ; do echo $i; done', I would say that it's not POSIX compatible. What
> > could/does depend on this behavior "working?"
> 
> It works for the realistic cases that might actually be useful.  E.g.,:
> 
> x=
> for i in $x; do
>   echo $i
> done
> 
> works fine.  I don't think it matters very much that the pathological
> case "for i in ; ..." doesn't work.

I just checked POSIX 1003.2.

for name [ in word ] 
do
compound-list
done

"First, the list of words following 'in' shall be expanded to generate
a list of items." [...] "If no items result from the expansion, the
compound-list shall not be executed."

 is not a word at all, so it can't be expanded, so I think
bash is corrent to complain about a syntax error.

It is clear, though, that your (John) example "variable expansion to
nothing" is not an error and both shells do it right.

To the original poster, it would have been useful to submit this as a
bug report or at least choose a subject line that indicates that
you're talking about the shell. I recognized the thread only when my
name was written and missed the beginning.

Martin
-- 
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message