🚀 go-pugleaf

In article <3527@taux01.UUCP> crehta@taux01.nsc.com (Ran Ever-Hadani) writes:
} In article <7960@ogicse.ogi.edu> schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes:
} 
} ># Bug: can't handle names beginning with + or ~
} >#  (use file completion: zfo +^[name where ^[ is escape)
} 
} Sorry, I missed that.  Anyway, this does not work for me for some
} reason.

Probably because you need to "set complete".  I should have mentioned that.

} >If it were easy to find and fix, believe me, I would have.  It isn't a
} >question of "finding" -- the problem is that the shell, which must be
} >used to run compress/uncompress with I/O redirected to or from the target
} >folder, does not understand "+" as a file metachar.  Without invoking
} >and additional process, say `echo +name | sed s/+/$folder/` (which fails
} >if $folder isn't set) there is no way for zfolder to use "+".
} 
} I am most grateful to the people who wrote and maintain mush.  Still,
} I don't see why invoking an additional process, after checking whether
} $folder exists, constitutes a problem.

It "constitutes a problem" because Mush itself can't do things like
the `echo ...` I mentioned -- there is no direct way to interpolate
*textual* command output into a mush command line; mush deals strictly
with message lists for purposes of `` and pipes.

} Better yet, I think it might be a good idea to add some mechanism
} to mush, allowing the user to convert the string +something to 
} $folder/something.  People may want to do extra-mush stuff other
} than zfolder with folders.

What could be done is to have the "sh" command expand all mush file
metacharacters before invoking the shell.  That would solve the problem
zfolder encounters.
-- 
Bart Schaefer          "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE"

                                                                    "THPPFT!"
schaefer@cse.ogi.edu (used to be cse.ogc.edu)