[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