Skip to Content.
Sympa Menu

sm-sorcery - Re: [SM-Sorcery]handling of $IFS

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: Aaron Brice <abrice2 AT cox.net>
  • Cc: sm-sorcery AT lists.ibiblio.org
  • Subject: Re: [SM-Sorcery]handling of $IFS
  • Date: 18 Oct 2002 03:44:04 -0400

I suppose it's possible to borrow a chapter from functional programming
and pass functions around:
function fs_for() {
local _func=$1
shift
local _fieldSep=$'\n'
if [[ $1 == with ]] ; then
shift
[[ $1 ]] && _fieldSep=$1 && shift
fi
while read -r -d ${_fieldSep} ; do
${_func} $* $REPLY
done
}

Then you would use it:
blahb lbha blha some code...
{
function itterate()
{
echo "Here is a line: $1";
}
fs_for "itterate" < filename
}
more code...
{
function itterate()
{
echo "Here is a word: $2 ($1)"
}
fs_for "itterate" with " " "with an arg" < filename
}

The second would chop it up by spaces (newlines with no space isn't good
enough), and would print "Here is a word <insert word> (with an arg)".
The functions itterate are not defined outside the { } that it is
enclosed in.

On Fri, 2002-10-18 at 03:11, Aaron Brice wrote:
> 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
Alternative II:
{
itterate()
{
LINE=$1 #or just use $1 instead...
...
}
search_depends_status "$SPELL" ".*" | fs_for itterate
}


>
> More overhead, but no IFS needed.
No IFS. Less overhead than using tail and head together (sed could be
used one insead of tail and head) since fs_for uses only builtins.
BTW, fs_for stands for Field Separator for.

>
> 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
>
>
--


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




Archive powered by MHonArc 2.6.24.

Top of Page