[darcs-devel] darcs patch: bash completion made more robust
regarding shell speci...
Guillaume
guillaume.outters at free.fr
Tue Dec 28 13:04:50 PST 2004
Le 28 déc. 2004, à 21:00, David Roundy a écrit :
> Thanks for your excellent explanation! Bash (or sh in general) really
> isn't
> one of my best skills. Amazingly enough, I did write the bash
> completion
> code... but it took a lot of copying and trial and error. :) And I've
> avoided touching it ever since.
It has become one of my well-known piece of software since, as a
paranoid hacker, I decided that I should be able to reproduce any
installation I do on my computer with a script, and, most importantly,
without interaction (errare humanum est). Since then, I am able to do
really ugly things with sh and sed, but I sometimes forget to comment
them, and… rereading 30-line sed scripts isn't easy when you rediscover
them after a 3-month hibernation.
> It's nice to have some explanation in the long comment for changes that
> aren't quite obvious. For really hard-to-understand changes, I
> sometimes
> prefer to not include a complete explanation in the comment.
OK, I'll comment them directly in the code, and summarize the shell
comments in the patch comment. I'll resubmit it with this magical
"darcs send" (I've been using darcs for three weeks and can't stop
discovering new useful features!). The new patch let bash' printf %q do
the job, which 1) is much cleaner and failsafe than doing it myself 2)
moves responsibilities onto bash team :-)
> Hmmm. True, we could do that. It'd seem like a bit of a shame
> though, to
> add an extra flag to all commands, just to better support command-line
> completion for silly people who have newlines in their filenames.
I like beginning coding features while imagining the trickiest cases
(that must be the reason why I'm not the only one to call me
paranoid…), so that I'm not embarassed in the end with a frozen
architecture. On the other hand, newline should be a sufficient
delimiter for that kind of thing.
In fact, as completion uses grep and I didn't find any reference to
grep being able to read its "lines" between nul chars instead of CR, it
would be unuseful here.
> I wonder if it would be a good idea to support NUL-delimited output on
> more
> commands? We could, for example, support it for annotate output (or the
> hypothetical query command), which could be helpful when viewing a
> listing
> of files in the repository. If there are enough such uses (and enough
> users for the uses) perhaps we should add a --nul-delimited flag that
> could
> be used by various commands to modify their output.
Yes, this could be interesting for those commands that output newlines.
I've not really looked at darcs code (please don't ask my Haskell
level!). Would it be easy to add such an all-commands flag, ignored by
all commands in the first implementation, and make commands adopt it
one by one, following demand and developer time availability?
It would only require for those commands to use a globally-defined
separator instead of a newline at some points (but, once again, how
this works in Haskell…).
--
Guillaume
More information about the darcs-devel
mailing list