Skip to Content.
Sympa Menu

sm-sorcery - Re: [SM-Sorcery]Re: CVS: sourcemage/sorcery/usr/sbin scribe,1.12,1.13

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: Ryan Abrams <rabrams AT sourcemage.org>
  • Cc: Sergey A Lipnevich <sergeyli AT pisem.net>, <sm-sorcery AT lists.ibiblio.org>
  • Subject: Re: [SM-Sorcery]Re: CVS: sourcemage/sorcery/usr/sbin scribe,1.12,1.13
  • Date: Thu, 24 Oct 2002 21:47:25 -0400 (EDT)

Hello

On Thu, 24 Oct 2002, Ryan Abrams wrote:

> Oh.. i understand the reasoning behind the pipes. I just find the lack
> of language stability disturbing in the extreme. A for loop is
> something I consider a given.. all these bash workarounds, while they
> work, can't be speedy, and can't be good for clean, obvious code. I
> enjoy pipes in everyday stuff.. but not in a large coding project as a
> workaround to basic structure and flow control.
Basic flow control is still there. What we did was remove a common type of
bubblegum ;)

>
> That said, if you can explain to me why "while read i; do ...; done <
> echo <list>" is actually better than "for i in <list>; do ...; done" I
> would love to hear it.
A for loop chukifies the list by whitespace, including spaces. If you want
to go line by line, but a line my have a space, for loop wil mess up
unless you play with the IFS.

>
> Oh, and i didn't code most of libcodex. Nathan Doss gets that honor. I
> just use it in scribe, and tweaked libcodex as needed. But yeah, it
> seems to pass values the correct way.
>
> I guess I am just getting tired of this crazy "spit an bubblegum" feel
> to the code, which is really do to all the myriad of crazy bashisms. I
> would rather have something clean, fast, and obvious.
Yay! No Perl :) I agree With Sergey on this point.

>
> -Ryan
>
> On Thursday, October 24, 2002, at 06:04 PM, Sergey A Lipnevich wrote:
>
> > I'd say, learn to appreciate the value of what you have before you
> > abandon it, but that's orthogonal to this discussion ;-). These are
> > not crazy pipes, these are necessary precations against spaces in
> > strings you get/pass through stdout. Explicit use of read makes one
> > aware of the fact that items can /only/ be separated with newlines,
> > not anything else. There's no environment passing from inside the
> > loop, is inconvenient. But guess what, you coded libcodex to pass
> > values via stdout, not via vars, which is the right way to do things
> > in bash I guess. After having used the pipes, I find them more elegant
> > then straightforward `for' ;-).
> > So, I'd say your logical decision should be not "screw bash", but
> > "screw global env vars as function results". A noble goal for 2.0, BTW
> > :-).
> >
> > Ryan Abrams wrote:
> >
> >> Sergey,
> >>
> >> In all honesty, I didn't follow the $IFS discussion much, if at all.
> >> That said, I understand the concept and concede the point. In my
> >> defense, scribe is completely separate from the things that seem to
> >> cause the issues... scribe is rarely called from anywhere else in
> >> sorcery (except system-update). This doesn't excuse the coding style
> >> (which I was unaware of), but it does mean it is less likely a
> >> problem. Still, feel free to correct the work. I just wanted to get
> >> it in there asap. Heck, the three new functions are all pretty much
> >> standalone except for calling codex_add_grimoire.
> >>
> >> On a related note, if the whole $IFS thing is what i think it is, it
> >> means we cannot even rely on basic programming constructs in bash.
> >> Instead we have to generate a list, then do crazy pipes to get things
> >> filtered through read to separate them. Thats insanity, and if that
> >> is the case then bash has got to go.
> >>
> >> -Ryan
> >>
> >> On Thursday, October 24, 2002, at 03:58 PM, Sergey A Lipnevich wrote:
> >>
> >>> Ryan,
> >>>
> >>> May I ask you to refrain from using "for i in <list>" construct when
> >>> <list> is a multi-line entity, for example the output of
> >>> `codex_get_all_grimoires`? You can use "echo <list> | while read i;
> >>> do ...; done" or "while read i; do ...; done < echo <list>" instead,
> >>> whichever you prefer, but please don't count on $IFS implicitly, or
> >>> on the fact that lines in the <list> don't have whitespace. I
> >>> daresay current "libcodex" may be a good example now that I cut out
> >>> all $IFS-dependent stuff. Since you seem to be passing return values
> >>> using "echo" instead of assigning global env variables, this must be
> >>> a really easy change.
> >>> Thanks!
> >>>
> >>> Sergey.
> >>>
> >>> rabrams AT cvs.sourcemage.org wrote:
> >>>
> >>
> >
> >
> > ------------------
> > Get free mailbox 20 Mb at http://www.hotbox.ru
>
> _______________________________________________
> SM-Sorcery mailing list
> SM-Sorcery AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
>

--


Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1






Archive powered by MHonArc 2.6.24.

Top of Page