sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
- From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
- To: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
- Cc: sm-sorcery AT lists.ibiblio.org
- Subject: Re: [SM-Sorcery]handling of $IFS
- Date: 18 Oct 2002 00:43:21 -0400
Nope, I'm not missing your point. There is just no easy fix. I've fought
with the IFS problems many many times and I've tried to find better
ways. Another thing that might help is running things in subshells, that
protects the parent from env var changes.
On Fri, 2002-10-18 at 00: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):
Please tell me you didn't copy and paste?
>
> save_ifs=$IFS
> $IFS=$enter_ifs
> for i in file-with-lines-with-spaces; do
> $IFS=$save_ifs
> do stuff
IFS=$ENTER_IFS or something was here I hope.
> done
> $IFS=$save_ifs
>
> Isn't it a bad hack?
Yes.
> 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.
I would agree. I have not found a way.
>
> --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
> >>
> >>
>
--
Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1
Attachment:
signature.asc
Description: This is a digitally signed message part
-
[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.