sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
- From: Aaron Brice <abrice2 AT cox.net>
- To: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
- Cc: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>, sm-sorcery AT lists.ibiblio.org
- Subject: Re: [SM-Sorcery]handling of $IFS
- Date: 18 Oct 2002 00:11:52 -0700
One alternative:
Old way (from satisfy_depends):
SAVED_IFS=$IFS
IFS=$ENTER_IFS
for LINE in `search_depends_status "$SPELL" ".*"`; do
IFS=$SAVED_IFS
...
done
Alternative:
DATA=`search_depends_status "$SPELL" ".*"`
DATALENGTH=`echo "$DATA" | wc -l`
i=1
while (( $i <= $DATALENGTH )); do
LINE=`echo "$DATA" | head -n $i | tail -n 1`
...
done
More overhead, but no IFS needed.
Aaron
On Thu, 2002-10-17 at 21:31, Sergey A. Lipnevich wrote:
> You seem to be missing my point. It's not /my/ code that I'm talking
> about, it's sorcery. And your solution does not work for 100% cases, as
> I have described below. It worked about four days ago for this part of
> code, then something's got changed, and it doesn't work anymore. Sorcery
> will keep bumping into $IFS whenever new code is introduced. If for
> instance awk can't be used to call a bash function, or some other way is
> invented to deal with this, I'd say $IFS will become a constant
> nightmare, as it happened to Nick ;-).
>
> E.g., consider this pice (takes place in libdepends):
>
> save_ifs=$IFS
> $IFS=$enter_ifs
> for i in file-with-lines-with-spaces; do
> $IFS=$save_ifs
> do stuff
> done
> $IFS=$save_ifs
>
> Isn't it a bad hack?
> One thing is clear from your answer: there's no way to reset $IFS to
> whatever we need and keep it this way. So I'd say we try and find the
> way to never touch $IFS at all, if at all possible.
>
> --Sergey.
>
> Dufflebunk wrote:
>
> >On Thu, 2002-10-17 at 19:34, Sergey A Lipnevich wrote:
> >
> >
> >>Hi All,
> >>
> >>Current sorcery again doesn't recognize the optional_depends, but in a
> >>subtle way. When the hash of these dependencies is converted into
> >>contents of $OPT, libdepends::satisfy_depends checks if the spell
> >>exists, and doesn't find it, so the spell is removed from hash. The
> >>reson for this is that in libcodex::codex_get_all_grimoires, the
> >>grimoire directories in the output are separated by ${IFS:1:1}, which
> >>appears to be either empty or something undesireable. I tried to fix
> >>
> >>
> >That should be a tab usualy.
> >
> >
> >
> >>this but finally realized that handling of $IFS in sorcery is going to
> >>become worse with time unless we stop changing its contents. I don't
> >>have a specific way out, but maybe we can get generate some smart ideas.
> >>Case a) it's the safest solution to leave $IFS alone, but parsing
> >>multiple line-files with `for' is not going to work, because usually
> >>such files contain spaces. Case b) If we reset $IFS to `<enter>' or
> >>`<enter><space><tab>' for the entire duration of sorcery commands,
> >>there's a danger that we will not be able to get it back to the original
> >>value if some kind of problem occurs and the sorcery is terminated (can
> >>signal handling help here?).
> >>
> >>
> >This is a bad idea as function arguments are also found using the IFS.
> >
> >
> >
> >>In case a), is it possible to run a
> >>line-editor like sed or awk, and call sorcery methods from there,
> >>instead of using `for i in <multi-line-file>; do...'?
> >>
> >>
> >That's a no-go. There may be instances where sections of code can be
> >replaced by sed and awk, but unfortunatly that's it.
> >
> >
> >
> >>Ideas?
> >>
> >>
> >If you need to go line by line, pad the for statement with IFS changers:
> >local oldIFS=$IFS
> >IFS=$ENTER_IFS
> >for line in $SOME_FILE ; do
> >IFS=$oldIFS
> >...
> >IFS=$ENTER_IFS
> >done
> >IFS=$oldIFS
> >
> >That the bast way I've found so far.
> >
> >
> >
> >
> >>--Sergey.
> >>
> >>----
> >>
> >>
> >>
> >
> >
> >
> >>ðÏÌÕÞÉÔÅ ÂÅÓÐÌÁÔÎÙÊ ÐÏÞÔÏ×ÙÊ ÑÝÉË 20í ÎÁ http://www.hotbox.ru
> >>
> >>
>
> _______________________________________________
> SM-Sorcery mailing list
> SM-Sorcery AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
-
[SM-Sorcery]handling of $IFS,
Sergey A Lipnevich, 10/17/2002
-
Re: [SM-Sorcery]handling of $IFS,
Nick Jennings, 10/17/2002
- Re: [SM-Sorcery]handling of $IFS, Sergey A. Lipnevich, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Dufflebunk, 10/17/2002
-
Re: [SM-Sorcery]handling of $IFS,
Sergey A. Lipnevich, 10/18/2002
- Re: [SM-Sorcery]handling of $IFS, Dufflebunk, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Nick Jennings, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Jens Laas, 10/18/2002
- Re: [SM-Sorcery]handling of $IFS, Sergey A Lipnevich, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Jens Laas, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Aaron Brice, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Dufflebunk, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Sergey A Lipnevich, 10/18/2002
- Re: [SM-Sorcery]handling of $IFS, Dufflebunk, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Sergey A Lipnevich, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Dufflebunk, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Sergey A. Lipnevich, 10/18/2002
-
Re: [SM-Sorcery]handling of $IFS,
Nick Jennings, 10/17/2002
Archive powered by MHonArc 2.6.24.