Re: [Bash-completion-devel] New bash-completion upstream, Fedora patches
On Tuesday 06 January 2009, David Paleino wrote: > On Tue, 6 Jan 2009 21:03:46 +0200, Ville Skyttä wrote: > > Hello, > > Hello Ville, > > > I noticed today that there's a new bash-completion upstream at > > alioth.debian.org - this is great, it's about time! > > Eheh :) > And we're having a newer upstream in our bzr repository ;) Sure, I noticed that :) > Are these patches tested enough? How long have they been applied in the > Fedora package? > We don't want another plethora of bugs *gh* ;) Depends. Some have been there for years, and I added 3 today while doing the rebase. Anyway, I'll use my best judgement what to commit and when. But then again, this is a upstream repository - shouldn't all new work go into this repository before exposing it to end users via e.g. distro packages? > Also, please subscribe to the mailing list Done, ditto the commits list. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] New bash-completion upstream, Fedora patches
On Tuesday 06 January 2009, you wrote: > On Tue, 6 Jan 2009 20:36:12 +0100, David Paleino wrote: > > However, please file a request to join the group: > > > > http://alioth.debian.org/projects/bash-completion/ > > Never mind, I've added you -- I just missed I could add a member myself :) Thanks. > Please, for the instructions on how to get the development repository, see > the homepage http://bash-completion.alioth.debian.org/ . Done. At least the sftp checkout worked, I'll test committing something trivial later this week. > Also, as best practice, please try to do atomic commits: one change (or > group of related changes), and its line in debian/changelog Certainly. I have no hands-on experience with bzr so I'll take some time to learn it before pushing anything. I do have experience with git and Mercurial though (and FWIW CVS, Subversion etc) so hopefully the learning will go smoothly. > We're still in a moment where bash-completion is > a "Debian-native" package, but we'll soon (I hope) split the tarball from > the Debian packaging, so we could have a sane ChangeLog in ./ . Or just something like NEWS which contains higher level changes; people interested in more details could just check the bzr logs? Anyway that would be welcome but as long as the changes are recorded somewhere and delivered to end users in understandable form, I don't think it's that crucial. I'm currently just using the Debian tarball and packaging debian/changelog in the Fedora package I pushed to the build system today - I don't think people will find the Debian specific things in it too overwhelming. rpm package specific changes of version updates etc go to %changelog in bash-completion.spec (the one in Fedora, not the one included in bash-completion although I'll have a look if there's something I should add to it from the Fedora one). But regarding missing files, I suppose a copy of http://www.gnu.org/licenses/gpl-2.0.txt is something that should be shipped in the tarball as soon as possible (probably as COPYING). > [0] Debian uses (Closes: #n), Ubuntu (LP: #n), it would be nice if > you used something like (Fedora: #) or, if you have a particular name > of your bugtracker, some abbreviation (if it was "Fedora BugZilla", "FBZ: > #" would be pretty fine to me) In other upstream projects I've usually used a full URL which looks like "https://bugzilla.redhat.com/nn"; . As far as I know there's no "official" abbreviation for it but I suppose the most often seen one is "rhbz". If you don't like the full URL, my 2nd preferred one would be (RHBZ: #nn). Let me know what you think. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] New completions: inline or separate files?
Hello, When adding completions for new, generally available commands, is it preferred to inline them in bash_completion or to add new files to contrib/? I gather there's a more or less active plan to split bash_completion into smaller files, maybe adding new completions as separate ones would make this process a bit easier? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [PATCHES] review some patches from Mandriva
Hi Guillaume, others, First a general question about the patches: are all of them written by you or contributed by other people? I'd like to be sure credit for them goes to the correct folks. Then, some comments about some of the patches, will try to take a look at the rest soon unless someone beats me to it: On Tuesday 13 January 2009, Santiago M. Mola wrote: > El lun, 12-01-2009 a las 23:55 +0100, Guillaume Rousse escribió: > > > Thoses patches correct some details in rpm completion: > > bash-completion-20060301-fix-old-rpmfiles-pattern.patch > > Looks good. Already taken care of in bzr as part of http://bzr.debian.org/loggerhead/bash-completion/current/revision/1232? > > bash-completion-20060301-rpm-macros.patch > > Is /etc/rpm/macros.d present on all rpm-based systems? If not, you may > want to check for its existence. Current bzr has an improved way of grabbing the list of available rpm macros that doesn't depend on any particular files (file based approaches to this tend to be incomplete and fragile (the bzr version isn't that pretty either but I think it's clearly an improvement)): http://bzr.debian.org/loggerhead/bash-completion/current/revision/1229? > > bash-completion-20090108-lzma-completion.patch Partially already applied/superseded in bzr, I intend to apply the rest tonight (I've had the patch around in Fedora packages for some time and it has worked fine). Will most likely commit the actual lzma completion as a separate file in contrib/ though. > > bash-completion-20060301-getent-completion.patch > > Looks good. Superseded in bzr: http://bzr.debian.org/loggerhead/bash-completion/current/revision/1240? As a general remark, I suggest taking a look at current bzr head and recent changes; I've committed quite a few things lately and there's still a few patches forthcoming. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [PATCHES] review some patches from Mandriva
On Tuesday 13 January 2009, Ville Skyttä wrote: > > bash-completion-20090108-lzma-completion.patch > Partially already applied/superseded in bzr, I intend to apply the rest > tonight Done with the following changes: - rpmbuild -tb/--tarball completes only on *.tar.lzma (did on all *.lzma) - fix completion of *.lzma filenames with spaces - fix OMPREPLY -> COMPREPLY typo - use _get_cword Also, I used -J for tar like GNU tar does. Is there a tar version out there that does lzma with -Y? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Remaining additions from Fedora
On Tuesday 13 January 2009, you wrote: > El mar, 13-01-2009 a las 20:10 +0200, Ville Skyttä escribió: > > As a general remark, I suggest taking a look at current bzr head and > > recent changes; I've committed quite a few things lately and there's > > still a few patches forthcoming. > > It'd be nice if you post them in the list for review, too ;-) Well, I don't think anybody brought that up when I asked about things last week (if someone did, I missed it - in that case my apologies!). Personally I'm a firm believer in post-commit review (instead of pre-commit) being the right thing for the vast majority of projects, and I don't see why it wouldn't be the right thing for bash-completion (and there's a commits list to facilitate that). Of course, will post anything I'm not quite sure of to get opinions before committing. Anyway, pre-commit review for my current bunch of patches is pretty much too late now, everything except a few new files is already in bzr. The remaining ones are: http://cvs.fedoraproject.org/viewvc/devel/bash-completion/ - bash-completion-lzop - bash-completion-mock - bash-completion-plague-client - bash-completion-repomanage lzop completion needs a trivial fix to support filenames with spaces (see for example gzip, bzip2, lzma in bzr). The last three used to be more or less Fedora centric but should be used by more setups nowadays and I suppose it doesn't hurt to add them to contrib/. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] New directory layout
On Tuesday 13 January 2009, Santiago M. Mola wrote: > Hi all, > > Based on the current aproach on Gentoo and on comments from other > distros, I'd like to propose a new directory layout for bash-completion. [...] > In Gentoo, we install all bash-completion modules > to /usr/share/bash-completion/. > > Modules are enabled system-wide when they're symlinked > from /etc/bash_completion.d/ and users can enable extra modules creating > symlinks in ~/.bash_completion.d/. > > We have a Gentoo-specific tool for handling these symlinks, but I guess > each distro would take its own aproach, which could be a) providing a > configuration interface, b) enabling all modules by default (like some > already do), c) let the user do it himself. In Fedora, we use rpm triggers to enable (symlink to /etc/bash_completion.d) additional completion modules whenever a package known to provide the needed commands is installed. > I think installing modules to /usr/share/bash-completion is more > consistent than the current state (I don't think bash-completion modules > can be considered anything near to configuration files). I agree, ditto also about the FHS part Guillaume mentioned. But the main bash_completion script falls into the above category in my opinion as well. Here's some food for thought: The main script: /usr/share/bash-completion/bash_completion Directory where all the bundled modules are installed, all packages installing additional modules should also drop theirs here; bash_completion does *not* load anything from here: /usr/share/bash-completion/modules/ Per user config file, loaded by bash_completion (just like it does now): ~/.bash_completion Directory for user to install/symlink additional modules to, bash_completion loads everything from here: ~/.bash_completion.d/ Directory reserved for local sysadmins to symlink/install additional system wide modules to (no packages should drop anything here), bash_completion loads everything from here: /etc/bash_completion.d/ Directory where OS default modules (e.g. ones enabled at additional package install time) are symlinked to, everything loaded by bash_completion; sysadmins or users should not touch this dir or its contents. Tools that manage system wide modules should operate on these files, not /etc/bash_completion.d/ ones: /var/lib/bash-completion # or maybe bash[-_]completion.d ? The OS and sysadmin distinction is there primarily to ensure that sysadmins and OS/package defaults don't stomp on each other. I'm not entirely sure if this is needed, but it could be useful. The order to load stuff could be: 1) ~/.bash_completion 2) ~/.bash_completion.d/* 3) /etc/bash_completion.d/* 4) /var/lib/bash-completion/* Then, have some kind of a blacklist mechanism (e.g. adding unwanted module names to let's say a bash_completion_blacklist array) that each of the above steps could use to prevent something from a later step from being loaded (and obviously to add some additional things): users can blacklist sysadmin (/etc/bash_completion.d) and OS (/var/lib/bash-completion) defaults, sysadmin can blacklist OS ones. It could obviously be done the other way around as well, by letting users undef stuff that has been enabled by a previous step, but that approach has the drawback that things a user may not want need to be loaded anyway, only to be undefined a bit later. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [patch review] Add/compact *Emacs, vi and friends indentation etc settings.
On Saturday 17 January 2009, Santiago M. Mola wrote: > revno: 1249 > committer: Ville Skyttä > branch nick: current > timestamp: Wed 2009-01-14 22:17:14 +0200 > message: > Add/compact *Emacs, vi and friends indentation etc settings. > > +# -*- mode: shell-script; sh-basic-offset: 8; indent-tabs-mode: t -*- > +# ex: ts=8 sw=8 et filetype=sh > > 4 spaces for each tab seems more extended in bash scripts than 8 spaces Not at all to me (assuming I understood correctly what you meant by extended). Having the default indent step equal to 4 spaces (or half a tab) and replacing all occurrences of 8 consecutive spaces with a tab is very common though, perhaps you meant that? Defining tab width (which is not the same thing as indent step) as something else than 8 causes very different results in editors/viewers that support the definition and ones that don't; I don't think that's a good idea. Tab == 8 spaces is a pretty much ubiquitous default everywhere. The intent of this patch was not to make any indentation changes but to be explicit what the current indent settings are, based on how I read the current sources. FWIW, changing the default indent step to 4 would be something I'd personally prefer, I believe it would be specified as # -*- mode: shell-script; sh-basic-offset: 4; indent-tabs-mode: t -*- # ex: ts=8 sw=4 sts=4 noet filetype=sh ...or for completeness, add "tab-width: 8" to the first line (but that would make it > 80 chars :(). (BTW my original change has a bug in the ex: line; "et" should have been "noet" in that too just like in the above, will fix that - thanks for making me take another look at it.) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [patch review] Add --rsyncable to gzip completion
On Saturday 17 January 2009, Santiago M. Mola wrote: > revno: 1252 > committer: Ville Skyttä > branch nick: current > timestamp: Thu 2009-01-15 00:38:07 +0200 > message: > Add --rsyncable to gzip completion (not in upstream gzip (yet?), but > commonly patched into various distros' packages). > > We should not be adding completion non-upstream things. That patch would > be better in distros who have the --rsyncable option for gzip. > Otherwise, people using upstream version are getting wrong completion. I'd argue the most usual source of incorrect completions are different options in different upstream software releases - options etc get added/removed/renamed all the time, and for many "same" commands there are even different upstreams. It's impossible to get everything right in every possible scenario in a project like bash-completion, and thus I think the project should focus on practical portability instead of strict "only upstream" or strictly lowest common denominator policy. In my opinion adding --rsyncable to gzip was practical based on checking the Linux distros I have access to or otherwise looked at their sources (Fedora, CentOS, openSUSE, Mandriva, Debian; all of these had --rsyncable). FWIW, just a couple of examples of support in one form or another for other non-upstream options discussed or applied during the last week or so which I think are practical enough to be applied at least for now: Debian specific (?) -l special case for man(1): -l either does not exist (for example man 1.6f which is the latest version for that upstream, and used by e.g. Fedora, Mandriva, CentOS (and I suppose also FreeBSD)) or means apparently something entirely different (for example Solaris, Tru64). --suggests, --enhances support for rpm(8): these do not exist in rpm from rpm.org, but I gather do exist in rpm from rpm5.org (different upstreams with differing opinions which is the "official" rpm). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] New directory layout
On Friday 16 January 2009, David Paleino wrote: > On Thu, 15 Jan 2009 23:18:16 +0200, Ville Skyttä wrote: > > The main script: > > /usr/share/bash-completion/bash_completion > > Oh well, if we move everything to /u/s/bash-completion/, calling it > "bash_completion" seems a bit redundant ;-) > > We could rename it to "core", "base", or something suggesting *that* is the > main file. Works for me. Except "core", that looks too much like a program crash dump. > > Per user config file, loaded by bash_completion (just like it does now): > >~/.bash_completion > > Uh, I didn't know we were sourcing ~/.bash_completion ;-) > Jokes aside, that's really a good idea. But, probably, that one should be a > "configuration file" -- i.e. it shouldn't contain any completion itself, > but rather tell the "core" file what to load from ~/.bash_completion.d/ or > /usr/share/bash-completion/modules. Works for me. But people are of course free to add whatever they want to their ~/.bash_completion. > > Directory for user to install/symlink additional modules to, > > bash_completion loads everything from here: > >~/.bash_completion.d/ > > Well, if ~/.bash_completion is a configuration file, we could make the > user decide what to load and not from his per-user directory. Works for me. > > /var/lib/bash-completion # or maybe bash[-_]completion.d ? > > I don't really like /var/lib/ -- but I'd have to check FHS for any other > suitable directory. I'll comment on this in a separate reply to Santiago's mail. > 1) /etc/bash_completion # read sysadmin's configuration, or provide > # distro-specific defaults here > 2) ~/.bash_completion # per-user configuration, shouldn't be > touched # by distro, overrides variables from /etc/ 3) ### see above > paragraph, the same steps go here. > > This way, we source the configuration variables (including this > blacklist-thing) *before* actually sourcing any completion, thus fixing the > "bug" of loading completions that would be undefined/blacklisted by the > user/sysadmin at a later step. I guess this is essentially the same as my original suggestion except that users could not preemptively use their ~/.bash_completion to prevent anything that happens in /etc/bash_completion. Whether that's a problem depends on what /etc/bash_completion contains. But then again, on a 2nd thought, I'm not quite sure that a mechanism for disabling complete completion modules is needed; the Mandriva approach of cherry-picking slow or otherwise problematic sections of some completions that users/sysadmins can configure to be skipped starts to make more and more sense to me. By the way, it's not quite clear to me at which point the "base" completion module would be loaded in the above. It'd be good to let users that don't want our stuff at all to opt out completely even if the stuff or a subset of it is installed and enabled in sysadmin configs. I failed to note and take this into account in my original brain dump - in that I was thinking that the "base" module is the orchestrator that is responsible for loading other configs and modules. So perhaps sourcing ~/.bash_completion and /etc/bash_completion should be moved to what's currently bash_completion.sh. Ooh, this is getting hairy. Writing a complete list of use cases we want to support and then working on based on that could be easier... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] New directory layout
On Friday 16 January 2009, Santiago M. Mola wrote: > El vie, 16-01-2009 a las 20:22 +0100, David Paleino escribió: > > On Thu, 15 Jan 2009 23:18:16 +0200, Ville Skyttä wrote: > > > > Directory where OS default modules (e.g. ones enabled at additional > > > package install time) are symlinked to, everything loaded by > > > bash_completion; sysadmins or users should not touch this dir or its > > > contents. Tools that manage system wide modules should operate on > > > these files, > > > not /etc/bash_completion.d/ ones: > > > /var/lib/bash-completion # or maybe bash[-_]completion.d ? > > > > I don't really like /var/lib/ -- but I'd have to check FHS for any other > > suitable directory. > > I don't like it either. And it's not FHS compliant anyway: > > From FHS: > > /var/lib : Variable state information > Purpose > This hierarchy holds state information pertaining to an application or > the system. State information is data that programs modify while they > run, and that pertains to one specific host. Users must never need to > modify files in /var/lib to configure a package's operation. > FHS compliance is the reason why I suggested /var/lib/bash-completion, and I think for the intended purpose it would be compliant. No actual modules would ever be *installed* there. It would just be a directory where modules to be enabled are *symlinked* to on per host basis (== state information for one specific host) *by tools* that enable/disable them (== programs modify while they run, state information for those tools, users don't modify). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [patch review] Add --rsyncable to gzip completion
On Saturday 17 January 2009, you wrote: > El sáb, 17-01-2009 a las 02:47 +0200, Ville Skyttä escribió: > > On Saturday 17 January 2009, Santiago M. Mola wrote: > David changed gzip completion to parse gzip --help, so it's fixed now. Good stuff. The implementation does seem to overlap the functionality of _longopt a bit though (or the other way around), but that's more or less cosmetic. Note about what follows: I'm not trying to be an ass or to force feed my opinions, but new here (but not new to bash-completion), rather trying to develop a gut feeling what people think bash-completion should or should not do. > > distros I have access to or otherwise looked at their sources (Fedora, > > CentOS, openSUSE, Mandriva, Debian; all of these had --rsyncable). > > That's still a tiny subset of available distros, Not really if you take into account the derivatives of those (which I assume do also carry that patch). But yep, then there's all the non-Linux environments where bash-completion is supposed to work as well. > which is quite opposite to "practical portability". I disagree. > Gentoo, for example, hasn't --rsyncable option. We'll always find some setups that do not have everything we expect, and we have to make assumptions. Nobody can test every setup available out there, and judgement calls have to be made. And we're all more or less biased - if Gentoo had --rsyncable, would you have objected to this addition? > I hope in the future we take the most generic approach (when possible), > specially when talking about distro-specific options. If the vast majority of target environments has something and a handful does not (patched in or not, and not specifically referring to gzip --rsyncable here), which one of these is the exception that we should leave to users or package maintainers of those environments? > That is, the lowest common denominator policy Personally, I certainly hope this is not going to happen. > or automatic guessing. If by this you mean things like parsing the available options dynamically from somewhere, it is clearly a winner when it can be done robustly. > On some projects, bash-completion modules are shipped with upstream > tarballs and maintained there, This is good (as long as they're really maintained in addition to being included)... > so people always have the correct version installed. ...but one problem is that a lot of upstream projects that ship completions do not actually install them, users or package maintainers need to take care of that. I suppose better filesystem layout for bash-completion and documentation about it could change this. Ditto mentioning what is the stable API (various helper functions etc) of bash-completion that external module writers can rely on being available. These would probably have a positive effect on more upstreams' willingness to include completion modules in their source trees and deliverables in the first place, not only the "include but do not install" part. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Keeping support for bash < 3.0?
Hello, What's the status of keeping support for bash < 3.0, do we have people around here who strongly think that it should be preserved and/or who regularly test with older versions? Personally, I don't have access to a box that has bash < 3.0 any more and thus I'm not able to test with those versions any more nor would mind them being dropped, but I'm not insisting dropping either. What prompted me to ask this question was an interesting looking patch posted to Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=479936 I suppose there would be possibilities for further cleanups/optimizations/simplifications if bash 3.0 was the oldest supported version. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Mandriva handling of bash completion
On Saturday 17 January 2009, David Paleino wrote: > Also, but this is something we should work on at a later time IMHO, there's > also the bash-completion-lib fork, which seems to "dinamically" load > completions when the command is typed. But that's just food for thought. Has merging with bash-completion-lib been discussed? It looks like very good stuff on the surface (haven't tried it myself). Merging could be quite painless now when the projects haven't drifted that far apart in other functionality. Some related efforts: https://bugzilla.redhat.com/show_bug.cgi?id=475229 http://groups.google.nl/group/gnu.bash.bug/browse_thread/thread/8f5d27d0d8b27bd7 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Mandriva handling of bash completion
On Saturday 17 January 2009, David Paleino wrote: > On Sat, 17 Jan 2009 20:34:10 +0200, Ville Skyttä wrote: > > > > Has merging with bash-completion-lib been discussed? [...] > I'll try some work in my (limited) spare time on merging the projects, and > announce the results here. Great, thanks! ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Keeping support for bash < 3.0?
On Saturday 17 January 2009, David Paleino wrote: > On Sat, 17 Jan 2009 20:20:14 +0200, Ville Skyttä wrote: > > What's the status of keeping support for bash < 3.0, do we have people > > around here who strongly think that it should be preserved and/or who > > regularly test with older versions? [...] > Would you mind setting up a wiki page for this, as well? http://wiki.debian.org/Teams/BashCompletion/Proposals/DropBash2Support ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Completions for review: lzop, repomanage
http://wiki.debian.org/Teams/BashCompletion/Reviews Ok, there's a couple of completions available for review in the to_review/ area, any takers? For those not familiar with it, repomanage is part of yum-utils, http://yum.baseurl.org/wiki/YumUtils ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Drop contrib/hg?
Hello, contrib/hg in bash-completion looks outdated compared to contrib/bash_completion shipped with Mercurial. Should it be dropped? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Mandriva handling of bash completion
On Sunday 18 January 2009, David Paleino wrote: > It's not smart loading everything on login, but it is doing it > when the command is actually being completed. So it's really needed, apart > from speed performance. Dumb question: has anyone evaluated the performance characteristics of if completion modules were instead of sourced shell functions implemented as executable scripts (not necessarily even shell ones) that would just be called with the appropriate environment and options, and that would echo their results to stdout, and used with complete -C? This way I suppose the amount of stuff to load at startup would decrease radically but the scripts would be continuously loaded and invoked anew for every completion in every shell. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Upstream BTS
On Saturday 24 January 2009, Guillaume Rousse wrote: > Additionaly, I'm not very found of using debian bts for discussing > bash-completion issues. I'd really prefer to distinguish between the > debian package and upstream code, as I have no clue about the potential > differences. Seconded. Alioth provides a tracker which could be a candidate for upstream (dunno how usable it is though), but looks like it has not been enabled for bash-completion: http://alioth.debian.org/tracker/?group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] _expand, scp and quoting
Hello, http://bzr.debian.org/loggerhead/bash-completion/current/revision/1170? I don't think the above change is actually wrong but it has broken at least "scp ~/" completion. This is because the "ls" in _scp ends up being run as ls -aF1d '~/*' 2>/dev/null ...and obviously ls '~/*' practically never matches anything because of the single quotes bash inserted. Before the above change there were no quoting problems because ~ was expanded to /home/foo which bash didn't need to enclose in single quotes. We'd want the ls to be run without the quotes, like ls -aF1d ~/* 2>/dev/null ...but I don't know how to get bash to do that. Ideas? On the other hand, I wonder what's the point of the ls -aF1d and sed spaghetti when completing _local_ files for scp in the first place. Wouldn't _filedir do just fine? Based on briefly browsing the code (note testing), the same problem could also be in "cvs add" although it probably isn't much of a problem for it (at least for the "~/*" case). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#512556: bash-completion: awk syntax error on 'modprobe -r /'
On Wednesday 21 January 2009, Colin Watson wrote:
> Typing 'modprobe -r /' produces the following output:
>
> $ modprobe -r /awk: {if (NR != 1 && $1 ~ /^//) print $1}
> awk: ^ syntax error
>
> I've attached a bzr bundle fixing this, based on a patch by Martin Mai.
> You can merge it with 'bzr merge
> /path/to/bash-completion-modprobe.bundle'.
The patch does indeed avoid this error but I don't think it's the correct
fix - the patch makes "modprobe -r /" complete on filenames but at least
on my Fedora 9 box with module-init-tools-3.4-13.fc9.x86_64, modprobe -r
doesn't operate on filenames but module names. BTW, rmmod completion "fixes"
the same awk problem by redirecting 2>/dev/null.
Hopefully better fix for both applied in
http://bzr.debian.org/loggerhead/bash-completion/current/revision/1290
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _expand, scp and quoting
On Wednesday 28 January 2009, David Paleino wrote: > On Sat, 24 Jan 2009 21:52:45 +0200, Ville Skyttä wrote: > > > I don't think the above change is actually wrong but it has broken at > > least "scp ~/" completion. This is because the "ls" in _scp ends up > > being run as > > > > ls -aF1d '~/*' 2>/dev/null > > > > ...and obviously ls '~/*' practically never matches anything because of > > the single quotes bash inserted. Before the above change there were no > > quoting problems because ~ was expanded to /home/foo which bash didn't > > need to enclose in single quotes. We'd want the ls to be run without the > > quotes, like > > > > ls -aF1d ~/* 2>/dev/null > > > > ...but I don't know how to get bash to do that. Ideas? > > Line 84, contrib/ssh -- but I suppose you already know that. Yes, that's one of the many things I've tried, to no avail. This is on Fedora 9, bash 3.2.33(1)-release > > On the other hand, I wonder what's the point of the ls -aF1d and sed > > spaghetti when completing _local_ files for scp in the first place. > > Wouldn't _filedir do just fine? > > Yes, or at least I believe so. I'd wait for others to comment on this as > well. Will wait a bit more, but my patience is getting thinner and thinner every time I hit this issue ;) > The fact is (I can't remember it right now, studying for exams and > can't recall if it's doable or not -- and that's why I can't decipher what > that sed hack is doing either): can we reliably find whether it's a local > path? Do we need to? Line 69 already checks for ":" in the argument and goes remote if found. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _expand, scp and quoting
On Saturday 24 January 2009, Ville Skyttä wrote: > Hello, > > http://bzr.debian.org/loggerhead/bash-completion/current/revision/1170? > > I don't think the above change is actually wrong but it has broken at > least "scp ~/" completion. I've looked into this some more. In addition to breaking _scp, it has also broken _java_packages when arguments start with ~. I thought I'd look for more things that might have been broken but just by looking at the two issues above I don't think it makes sense to spend more time in searching, it's quite clear that there are and/or will be more things broken in subtle, hard to notice ways when arguments start with ~ (when accessed in commands, bash quotes the tilde instead of expanding it). I've reverted the above and added some comments to _expand, I think the slight (subjective) annoyance reported in Debian #489720 is a small price to pay for less hard to find bugs. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 6c27cd16ddf9353d02f6385da21505e1b2e10604
On Thursday 12 February 2009, Guillaume Rousse wrote: > The following commit has been merged in the master branch: > commit 6c27cd16ddf9353d02f6385da21505e1b2e10604 > Author: Guillaume Rousse > Date: Thu Feb 12 22:12:20 2009 +0100 > > - split _command function in two different functions: > _command now only computes where wrapped command start > _command_offset actually takes care of running wrapped command > completion > - drop _remove_comp_word function, as context rewriting is now > performed more efficiently in _command_offset > - drop strace minimal completion, there is a better dedicated > completion waiting review Sounds useful, but I think at least the last one should have been a separate commit as it seems entirely unrelated to the others. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Reply-To for -commits list
Hi, I think it would be good to set Reply-To to bash-completion-devel for all messages on the -commits list. This is based on the assumption that discussion about commits should take place on -devel, not -commits (I'm not sure if people can post to the latter directly anyway). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] bash_completion.sh executable?
Hi David, others, Is there a reason why bash_completion.sh is executable? It's sourced, not executed, so I think not. I've fixed the permissions already once in bzr, but it was (seemingly intentionally) unfixed shortly afterwards: http://git.debian.org/?p=bash-completion/bash-completion.git;a=commit;h=d49c7c4d88314cce7987651cd208de3d5882c4a8 http://git.debian.org/?p=bash-completion/bash-completion.git;a=commit;h=fe41b80fba17cbbe843b757e7c43e09d0bb6a522 David, I mailed you when I saw this happened, but I don't remember hearing back. Did I miss something? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Wednesday 04 February 2009, David Paleino wrote: > On Wed, 04 Feb 2009 21:59:25 +0100, Guillaume Rousse wrote: > > Freddy Vulto a écrit : > > > Just wanted to propose a roadmap, so focus gets to where it's needed: > > > > > > 1. Settle for a Version Control System (VCS) and Bug Tracking System > > > (BTS). > > > > > > 2. Merge bash-completion-lib's test suite > > > > > > 3. Branch current development. Release as bash_completion-2. > > > > > > 4. Break with bash-2 backwards compatibility. Decide on new directory > > > layout. Release as bash_completion-3. > > > > > > 5. Merge bash-completion-lib. > > > > I'd insert the following items between 1 and 2, or between 2 and 3: > > - finish splitting every command into its own file > > - finish reviewing new completions > > Agreed. I'd rather see a real release being made before "split every command" takes place, no objections otherwise. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Friday 13 February 2009, Freddy Vulto wrote: > David Paleino gmail.com> writes: > > On Fri, 13 Feb 2009 00:11:41 +0200, Ville Skyttä wrote: > > > On Wednesday 04 February 2009, David Paleino wrote: > > > > On Wed, 04 Feb 2009 21:59:25 +0100, Guillaume Rousse wrote: > > > > > I'd insert the following items between 1 and 2, or between 2 and 3: > > > > > - finish splitting every command into its own file > > > > > - finish reviewing new completions > > > > > > > > Agreed. > > > > > > I'd rather see a real release being made before "split every command" > > > takes place, no objections otherwise. > > > > Well, releasing another headache-making bash-completion doesn't really > > sound good to me :) > > Isn't there a concern that "splitting every command into its own file" is > going to make bash_completion slower? If so, maybe we'd better release > bash_completion-2 (or ..200902xx) with the improvements made so far, stop > supporting bash-2, branch and make the "splitting every command into its > own file" part of the new branch: bash_completion-3? +1 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Saturday 14 February 2009, David Paleino wrote: > On Fri, 13 Feb 2009 14:14:29 + (UTC), Freddy Vulto wrote: > > [..] maybe we'd better release bash_completion-2 (or ..200902xx) [..] > > I was starting a branch for the release process... what version number you > believe is "sane"? > > I'd start at 1.0, (so as not to be necessarily linked to the bash version), > and the "date" format is kinda weird to me. Going from 200902xx to 1.0 (or just about anything else) will cause some headaches with package updates. In rpm land Epoch would need to be used, dunno about other package formats but I suppose they have similar mechanisms. I have no problem with that, it's obviously doable, just thought I'd mention it in case someone didn't think of it. I wouldn't have any problem with sticking with date based versions either, but I suppose it would be confusing in case someone intends to maintain two separate branches (does someone?). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Drop contrib/hg?
On Sunday 18 January 2009, Ville Skyttä wrote: > Hello, > > contrib/hg in bash-completion looks outdated compared to > contrib/bash_completion shipped with Mercurial. Should it be dropped? Done. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] vncviewer
On Sunday 15 February 2009, Freddy Vulto wrote: > The following commit has been merged in the master branch: > commit 20278a41473544d43c51095ba2e118fc7b89c0d5 > Author: Freddy Vulto > Date: Sun Feb 15 21:56:01 2009 +0100 > > Reviewed `to_review/vncviewer': > - added support for case-insensitive options > - added support for double-dash > - replaced options with options from vncviewer-4.1.1 (Ubuntu-8.10) There's already vncviewer completion in the main bash_completion file, and it seems to do something quite funky the to_review/ one does not. I don't have a clue about vncviewer, just making sure that people looking into this are aware that there are two implementations and are prepared to merge them when/if appropriate, and remove the "built-in" one when the to_review/ one graduates. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Using launchpad as bugtracker?
On Monday 23 February 2009, David Paleino wrote: > Hello, > what do you think of using Launchpad as bugtracker? No strong objections, but I'd prefer something that can "naturally" link bugs with commits in the SCM (and have the links go both ways in the BTS and SCM web interfaces), and generally one logical site for all project activities. I haven't really used launchpad, but a quick Google search didn't tell me that git/gitweb would be available there. I don't know of a site that would have everything the way I'd like; fedorahosted.org has most features I generally like to see but not all of them are really top notch implementations, sourceforge's tracker sucks as much as alioth's etc. Crosslinking distro bugs in launchpad sounds like a nifty feature, perhaps enough to trump lack of nice BTS<->SCM integration if those are the things to choose from. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Using launchpad as bugtracker?
On Monday 23 February 2009, David Paleino wrote: > On Mon, 23 Feb 2009 19:56:31 +0200, Ville Skyttä wrote: > > On Monday 23 February 2009, David Paleino wrote: > > > Hello, > > > what do you think of using Launchpad as bugtracker? > > > > No strong objections, but I'd prefer something that can "naturally" link > > bugs with commits in the SCM (and have the links go both ways in the BTS > > and SCM web interfaces), > > Well, Alioth isn't doing that now :/. No, it isn't, but aren't we looking for something better anyway ;) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Using launchpad as bugtracker?
On Monday 23 February 2009, David Paleino wrote: > On Mon, 23 Feb 2009 19:07:55 +0100, David Paleino wrote: > > On Mon, 23 Feb 2009 19:56:31 +0200, Ville Skyttä wrote: > > > I haven't really used launchpad, but a quick Google search didn't tell > > > me that git/gitweb would be available there. > > > > Yes, but I believe we could ask LP people to add it? Who knows? :) > > > > /me joins #launchpad on some network and asks. > > Ok, after some talking with a guy, LP is definitely not going to support > git. Too much work in its maintainance, integrating with LP, [..]. ...and I guess its license means that nobody else will be doing that either. D'oh :( > But, *but*: [...] > So we would eventually get some kind of SCM<>BTS integration. Sounds promising. > But also, > before July, it is possible that Alioth upgrades to FusionForge (a GForge > fork) -- maybe we could expect more features there? Going to ask Alioth > admins. Personally, I don't have anything against waiting until July to see what happens, and keeping the current setup until that. But as said, no strong objections to doing something before that either if people find it feasible. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#516614: Bug#516614: Bug#516614: ps2pdf works on .pdf files as well
On Sunday 22 February 2009, James Westby wrote: > On Sun, 2009-02-22 at 16:55 +, James Westby wrote: > > Package: bash-completion > > Version: 20080705ubuntu3 > > Severity: normal > > Tags: patch > > > > Hi, > > > > In https://bugs.launchpad.net/bugs/316943 Jakob Unterwurzacher noted that > > ps2pdf also works on .pdf files. > > > > Patch will be forthcoming. > > Here it is. Applied, thanks. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#521406: bash-completion: leading tilde always expanded
On Friday 27 March 2009, deb...@ginguppin.de wrote: > Package: bash-completion > Version: 20080705 > Severity: normal > > completing pathes like ~/foo to /home/username/foo is usually unwanted -- > and there seems to be non configuration to disable it gracefully. We had the expansion disabled for a while and it resulted in things breaking, so the expansion is back and I don't personally think it's going away any time soon. See for example http://lists.alioth.debian.org/pipermail/bash- completion-devel/2009-February/000973.html ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] mencoder profile completion
On Friday 27 March 2009, gibbo...@gmail.com wrote:
> Hello,
>
> the mencoder use profile as mplayer.
> But mencoder can take its profile definition from another file than
> .mplayer/config which is .mplayer/mencoder.conf as stated in the man
> page.
> Also I'm asking if it's possible to this filename to the sed command
> line 6088 of git ('-profile' entry of 'case $prev').
> (It would be proper to define the filename .mplayer/$afilename according
> to $cmd (mencoder profile are not usefull with mplayer and vice-versa))
> Proposition, replacing :
> local profiles=$(sed -ne 's|\[\(.*\)\]|\1|p' ~/.mplayer/config)
> by
> local aprofile = 'config'
> [[ "$cmd" == 'mencoder' ]] && aprofile = 'mencoder.conf'
> local profiles=$(sed -ne 's|\[\(.*\)\]|\1|p' "~/.mplayer/${aprofile}")
Done in git, thanks for the suggestion.
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] mencoder profile completion
On Saturday 28 March 2009, Ville Skyttä wrote:
> On Friday 27 March 2009, gibbo...@gmail.com wrote:
> > Proposition, replacing :
> > local profiles=$(sed -ne 's|\[\(.*\)\]|\1|p' ~/.mplayer/config)
> > by
> > local aprofile = 'config'
> > [[ "$cmd" == 'mencoder' ]] && aprofile = 'mencoder.conf'
> > local profiles=$(sed -ne 's|\[\(.*\)\]|\1|p' "~/.mplayer/${aprofile}")
>
> Done in git, thanks for the suggestion.
On a second thought, done with _mplayer_options_list instead of accessing
config files directly.
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 0f2656669fbdf627a3ddf11bdb72e3ec9cef68fd
On Monday 30 March 2009, Guillaume Rousse wrote: > Guillaume Rousse a écrit : > > The following commit has been merged in the master branch: > > commit 0924d059c6c845069b10482882c821088ccaeefa > > Merge: 91daa8de58a6e88d5a4b55621e2e7d5e732c65ea > > dc88329e8eea8424f2e1dc7efc50a80e240708c4 Author: Guillaume Rousse > > > > Date: Mon Mar 30 22:02:55 2009 +0200 > > > > Merge branch 'master' into guillomovitch > > This seems to be a commit related to my own local branch, I don't > understand why it does generate a mail here... I just hop I don't screw > up anything in master branch. Happened to me too once, I don't claim to understand it either but it didn't seem to have any bad effects. The web UI doesn't show any changes the usual way either, just "Simple merge", just as it did for me as well. http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=0924d059c6c845069b10482882c821088ccaeefa > Also, when merging changes from my own branches into master branch, how > can I merge multiples commits into single ones, so as to ditch invalid > intermediate steps ? I don't know, but the way I do it is that I clean up my commits locally before pushing them using git commit --amend. For example: # hack bash_completion git add bash_completion git commit # hack bash_completion more, related to the previous commit git add bash_completion git commit --amend # then edit the commit message if appropriate The result of the above is a clean single local commit. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] bash 2.x array initialization
On Monday 30 March 2009, Ville Skyttä wrote: > The following commit has been merged in the master branch: > commit afa40dea93309b5e793613858f0c18cf35ec9f12 > Author: Ville Skyttä > Date: Mon Mar 30 23:53:23 2009 +0300 > > Fix local array initialization under bash 2.x. > > In bash 2.x, "local foo=(bar)" does not appear to initialize foo to > an array containing "bar", but to the non-array value "(bar)". This fix is something we definitely want in 1.0 too - without it, all _filedir completions get a "()" entry included in them under bash 2.x. I saw 1.0 was already tagged but I don't know how the branch is supposed to be managed and by whom (there's no mention of 1.0 in the roadmap proposal) so I've committed this only to master. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] bash 2.x array initialization
On Tuesday 31 March 2009, Ville Skyttä wrote: > On Monday 30 March 2009, Ville Skyttä wrote: > > The following commit has been merged in the master branch: > > commit afa40dea93309b5e793613858f0c18cf35ec9f12 > > Author: Ville Skyttä > > Date: Mon Mar 30 23:53:23 2009 +0300 > > > > Fix local array initialization under bash 2.x. > > > > In bash 2.x, "local foo=(bar)" does not appear to initialize foo to > > an array containing "bar", but to the non-array value "(bar)". > > This fix is something we definitely want in 1.0 too - without it, all > _filedir completions get a "()" entry included in them under bash 2.x. > > I saw 1.0 was already tagged but I don't know how the branch is supposed to > be managed and by whom (there's no mention of 1.0 in the roadmap proposal) > so I've committed this only to master. Oops. I thought I was testing bash 2.x but in fact it was bash "3.00.15(1)- release" on CentOS 4. And I made quite a mess of amending the original commit :(. The stuff desirable in 1.0 is these two changes: http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=15594d6c08cf0cd76fe5918ff17dd4637bf6394b http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=cb61c92f7147ab904962a662cb56ab95927f74f7 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, frozen/1.0, updated. 79ef58feca717e6872f4696fd7e7db8f7dc57d0b
On Tuesday 31 March 2009, David Paleino wrote: > The following commit has been merged in the frozen/1.0 branch: > commit 79ef58feca717e6872f4696fd7e7db8f7dc57d0b > Author: Ville Skyttä > Date: Mon Mar 30 23:53:23 2009 +0300 > > Fix local array initialization under bash 3.0. > > In bash 3.0, "local foo=(bar)" does not appear to initialize foo to > an array containing "bar", but to the non-array value "(bar)". > > diff --git a/CHANGES b/CHANGES > index 3f31302..d7365ff 100644 > --- a/CHANGES > +++ b/CHANGES > @@ -141,6 +141,12 @@ bash-completion (1.0) >* Remove obsolete --buildarch and --buildos rpm(build) completions. >* Add rpmbuild --target completion. >* Use "-profile help" to get mplayer and friends -profile completions. > + * Split yum and yum-arch completion into contrib/yum. > + * Install yum-arch completion only if yum-arch is installed. > + * Update list of yum commands and options. > + * Add yum repolist, --enable/disablerepo, and --disableexcludes > completions. These four added lines should not have been added to 1.0 because the actual changes they describe are not in 1.0, they're only in master. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 0f2656669fbdf627a3ddf11bdb72e3ec9cef68fd
On Tuesday 31 March 2009, David Paleino wrote: > On Mon, 30 Mar 2009 23:50:53 +0300, Ville Skyttä wrote: > > On Monday 30 March 2009, Guillaume Rousse wrote: > > > Guillaume Rousse a écrit : > > > > The following commit has been merged in the master branch: > > > > commit 0924d059c6c845069b10482882c821088ccaeefa > > > > Merge: 91daa8de58a6e88d5a4b55621e2e7d5e732c65ea > > > > dc88329e8eea8424f2e1dc7efc50a80e240708c4 Author: Guillaume Rousse > > > > > > > > Date: Mon Mar 30 22:02:55 2009 +0200 > > > > > > > > Merge branch 'master' into guillomovitch > > > > > > This seems to be a commit related to my own local branch, I don't > > > understand why it does generate a mail here... I just hop I don't screw > > > up anything in master branch. > > > > Happened to me too once, I don't claim to understand it either but it > > didn't seem to have any bad effects. The web UI doesn't show any changes > > the usual way either, just "Simple merge", just as it did for me as well. > > But "git log" is a mess, and cherry-picking isn't easy. > > What are you guys using? Plain git CLI. > What's your development workflow? git pull -u, hack something, test, commit locally, push. Sometimes there are longish time periods between these steps, sometimes commit amending, rebasing etc are involved as well. > There shouldn't be any merges in master. > > So log messages like: > > Merge branch 'master' of > git+ssh://scop-gu...@git.debian.org/git/bash-completion/bash-completion > > should'nt really exist, sorry :) I think it occurs in this scenario: 1) git pull -u --> everything up to date now 2) git commit --> commit locally, no push 3) Meanwhile, someone else commits something to the origin branch 4) git push (There might be another "git pull -u" between 3) and 4), and the merge message might come from that.) > > I don't know, but the way I do it is that I clean up my commits locally > > before pushing them using git commit --amend. For example: > > > > # hack bash_completion > > git add bash_completion > > git commit > > > > # hack bash_completion more, related to the previous commit > > git add bash_completion > > git commit --amend # then edit the commit message if appropriate > > > > The result of the above is a clean single local commit. > > Right. > You do this in master? Yes, in my local clone of it. > After this, do you do a simple push? Yes. > I'd like to have a clean log, so as in future we could have some > automagical tool generating a changelog from "git log" (as git-dch now does > for debian/changelog) But if done properly, the above amend procedure will create a clean log (only one commit entry). When not done properly, it'll create a mess which is now visible in top of master's log, thanks to yours truly. OTOH, I'm not sure if amending works too nicely or at all if the commit one wishes to amend is not the latest one (there's the -c/-C option to commit but I'm not sure if I've ever used it). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] bash 2.x array initialization
On Tuesday 31 March 2009, David Paleino wrote: > On Tue, 31 Mar 2009 00:13:33 +0300, Ville Skyttä wrote: > > > I saw 1.0 was already tagged but I don't know how the branch is supposed > > to be managed > > That branch is really bad named, sorry for not thinking at the future when > creating it. It should have been "1.x", or kinda. It's really the 1.x > branch, so when we release 1.0, we can continue bugfixing with 1.1, 1.2, > 1.3, cherry-picking from master and releasing tags from the "1.x" branch, > while continuing "experimental development" in master. Clear enough? :) Works for me. Even better if it was documented in Wiki ;) > If you have other suggestions, please tell :P Maybe a bit off topic, but here goes: - Remove to_review/ from 1.0 branch and do reviews only in master. - Maybe remove extra/ from 1.0 because debian/ was removed as well. - Remove bash-completion.spec from all branches unless someone wants to update and maintain it. - Add autotools stuff to master if that's what we're going to be using. - Add CHANGES to master. - Consider removing debian/ and extra/ from master as well, or lay out and document rules who should touch those dirs and when (for example I think it's quite tedious to keep updating both debian/changelog and CHANGES). > > and by whom > > Should we appoint release managers? I believe no. See the mess we have in > Debian when having a release :P :) If we can keep actually releasing stuff (it's been quite a while since the last release) and keep the various branches focused on their intended purpose, I don't care. But I do think some kind of a branch maintainer (can also be a group) role would be welcome - those interested in maintaining a specific branch should be the only ones fixing branch specific issues, cherry picking from other branches etc and generally committing to it - it's quite inefficient if each committer always has to even consider committing/adapting all ones changes to N branches. > I thought it was clear -- my intentions were to release bash-completion in > February, but I only had time now. > If you're against a release, I haven't announced it yet, so we're still in > time. No objections, on the contrary actually! Except that I'd prefer if the yum related entries in CHANGES that crept in without the corresponding actual code changes could be dropped before the release (see commit 79ef58feca717e6872f4696fd7e7db8f7dc57d0b). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 0f2656669fbdf627a3ddf11bdb72e3ec9cef68fd
On Tuesday 31 March 2009, David Paleino wrote: > On Tue, 31 Mar 2009 20:10:17 +0300, Ville Skyttä wrote: > > On Tuesday 31 March 2009, David Paleino wrote: > > > But "git log" is a mess, and cherry-picking isn't easy. > > > > > > What are you guys using? > > > > Plain git CLI. > > Eh, I meant "which git command", sorry for not being clearer. git log, git cherry-pick, sometimes qgit for viewing the history and browsing diffs. > Ah. Well, I read somewhere that rebasing, when working on shared, published > repsoitories, is *evil*. OTOH, I can't recall why it's bad It's bad if done *in* a published repository because it essentially rewrites history. I don't see anything wrong with it when done only in local working copies which aren't published/shared anywhere. > -- and I never > used it, really. Why are you using it? In which cases? Whenever I have local commits that haven't for whatever reason made it to the upstream repository which has moved on. Granted, I use it mostly with projects where I don't have commit access, dunno if I've used it with bash- completion. > -u, --update-head-ok > By default git-fetch refuses to update the head which corresponds > to the current branch. This flag disables the check. This is purely > for the internal use for git-pull to communicate with git-fetch, > and unless you are implementing your own Porcelain you are not > ^^ > supposed to use it. > ^^ > Is there any reason why you -u? Yes, muscle memory. When I started learning git, I probably read some instructions that said "git pull -u" corresponds to say "cvs update" and have not bothered to re-check that habit afterwards. I'll look into dropping the habit. > > thanks to yours truly. > > My what? Nothing :). "Yours truly" == me in a message written by me. http://dictionary.reference.com/browse/yours+truly http://en.wikipedia.org/wiki/Valediction#Yours_truly.2C ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, frozen/1.0, updated. 79ef58feca717e6872f4696fd7e7db8f7dc57d0b
On Tuesday 31 March 2009, David Paleino wrote: > On Tue, 31 Mar 2009 20:13:33 +0300, Ville Skyttä wrote: > > On Tuesday 31 March 2009, David Paleino wrote: > > > diff --git a/CHANGES b/CHANGES > > > index 3f31302..d7365ff 100644 > > > --- a/CHANGES > > > +++ b/CHANGES > > > @@ -141,6 +141,12 @@ bash-completion (1.0) > > >* Remove obsolete --buildarch and --buildos rpm(build) completions. > > >* Add rpmbuild --target completion. > > >* Use "-profile help" to get mplayer and friends -profile > > > completions. + * Split yum and yum-arch completion into contrib/yum. > > > + * Install yum-arch completion only if yum-arch is installed. > > > + * Update list of yum commands and options. > > > + * Add yum repolist, --enable/disablerepo, and --disableexcludes > > > completions. > > > > These four added lines should not have been added to 1.0 because the > > actual changes they describe are not in 1.0, they're only in master. > > Fixed :) > Please next time do separate logical commits :P I did. http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=aa2851d54975588a043e7a53434c7d4f1fbbf3fb http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=2e56e545804e807b8dd17c631fe84542af9a226f http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=ab46b349a48ac5bc8236c23e2af39babdefb6911 http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=23e1851605a9811a76dfcb118c7a1c1b6ae6a670 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] bash 2.x array initialization
On Tuesday 31 March 2009, David Paleino wrote:
> On Tue, 31 Mar 2009 20:36:43 +0300, Ville Skyttä wrote:
> Wiki updated:
>
> http://wiki.debian.org/Teams/BashCompletion/Git
Thanks.
> From now on: debian/changelog is no more used as upstream changelog
> (CHANGES will be), and no one is supposed to touch debian/*, except for
> Debian maintainers (which is only me, at the moment), Yet it's still useful
> to keep log of the closed Debian bugs in CHANGES (as well as other BTS's),
> so let's use this format in CHANGES from now on:
>
> : # → 's BTS
>
> example:
>
> Debian: #, Ubuntu: # (let's keep it "Ubuntu" also for
> {K,X,Ed,*}ubuntu), Gentoo: #, [..]
>
> If you agree, I'll start editing CHANGES (oh, my.) to keep it
> "policy-compliant" :)
Sure, works for me.
CHANGES in master is currently lagging a bit behind debian/changelog (at least
the yum changes I committed, maybe something from Guillaume), will you bring
it up to date as well while at it? I have some local stuff ready to
commit+push but I can wait for CHANGES to catch up before I do. Yell if you
need help with this.
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] "make" filename completion
Hi, The completion of make and friends currently has: complete -f -F _make $filenames make gmake gnumake pmake The -f seems to break for example "make -C " so that it completes on dirs+files instead of just dirs. Simply changing the line to complete -F _make $filenames make gmake gnumake pmake ...fixes that. But it also changes for example "make " to no longer complete on files. I'm not sure whether this would be desirable or a problem. Anyone? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [PATCH] yum: Complete on filenames when $cur contains /
On Wednesday 01 April 2009, Todd Zullinger wrote: > Greetings, > > I whipped this up in response to some discussion in #fedora-devel the > other day, noting that it was not possible to complete on filenames > using bash-completion's yum function. This isn't perfect, but it does > at least allow for filename completion when the user has explicitly > started to type a path. > > If you'd prefer patches in another form or place, please let me know. > This patch is meant to apply with git am, to master. I can rebase it > to the 1.x branch if that's preferable. Applied, thanks. git am for master is perfect, the only slight improvement would have been an entry in CHANGES (I added one for this change). ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] "make" filename completion
On Tuesday 31 March 2009, Ville Skyttä wrote: > Hi, > > The completion of make and friends currently has: > > complete -f -F _make $filenames make gmake gnumake pmake > > The -f seems to break for example "make -C " so that it completes on > dirs+files instead of just dirs. Simply changing the line to > > complete -F _make $filenames make gmake gnumake pmake > > ...fixes that. But it also changes for example "make " to no longer > complete on files. I'm not sure whether this would be desirable or a > problem. Anyone? I *think* it isn't a problem, so I've committed this change to master. It can always be reverted if this turns out not being the right thing to do. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] RFC: Better long option with argument completion
Hello,
Currently completion of long options that take arguments is pretty bad. For
an example, many completions list things like "--foo=" in their compgen -W
strings which end up completed as "--foo\= " which is annoying, especially the
trailing space. Some completions use "internal" workarounds for this which is
suboptimal from maintenance point of view.
With bash 4.x I suppose we could use compopt -o nospace but I suggest doing
something about this already now.
So I came up with the attached patch. The idea is that for all long options
that take an argument and can take it in both "--foo=bar" and "--foo bar"
forms, we only list "--foo" (not "--foo=") in completions, run it through
_split_longopt, and code the completion logic as if "--foo bar" had been
passed and it'll work for both "--foo=bar" and "--foo bar".
Additionally, using the return value of _split_longopt we can "return 0" early
to avoid doing potentially weird/slow things with last resort default
completions later when a --foo=bar thing is being completed and we don't have
specific completions for the required argument for --foo (the assumption being
that if --foo= is specified, --foo requires an argument).
The attached patch contains _split_longopt and a few modifications to existing
completions to illustrate its usage and how it helps and what kind of cleanups
and improved features it allows.
Comments? I would like to commit _split_longopt soon and start changing
existing completions to use it.
diff --git a/bash_completion b/bash_completion
index 688adbd..ea3e433 100644
--- a/bash_completion
+++ b/bash_completion
@@ -317,6 +317,23 @@ _filedir()
COMPREPLY=( "${comprep...@]}" "${to...@]}" )
}
+# This function splits $cur=--foo=bar into $prev=--foo, $cur=bar, making it
+# easier to support both "--foo bar" and "--foo=bar" style completions.
+# Returns 0 if current option was split, 1 otherwise.
+#
+_split_longopt()
+{
+ if [[ "$cur" == --?*=* ]]; then
+ # Cut also backslash before '=' in case it ended up there
+ # for some reason.
+ prev="${cur%%?(\\)=*}"
+ cur="${cur#*=}"
+ return 0
+ fi
+
+ return 1
+}
+
# This function tries to parse the output of $command --help
#
_parse_help() {
@@ -776,14 +793,30 @@ complete -F _service service
#
_chown()
{
- local cur
+ local cur prev split=false
cur=`_get_cword`
+ prev=${COMP_WORDS[COMP_CWORD-1]}
+
+ _split_longopt && split=true
+
+ case "$prev" in
+ --from)
+ _usergroup
+ return 0
+ ;;
+ --reference)
+ _filedir
+ return 0
+ ;;
+ esac
+
+ $split && return 0
# options completion
if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W '-c -h -f -R -v --changes \
- --dereference --no-dereference --from= --silent --quiet \
- --reference= --recursive --verbose --help --version' -- $cur ) )
+ --dereference --no-dereference --from --silent --quiet \
+ --reference --recursive --verbose --help --version' -- $cur ) )
else
_count_args
@@ -803,18 +836,27 @@ complete -F _chown $filenames chown
#
_chgrp()
{
- local cur prev
+ local cur prev split=false
COMPREPLY=()
cur=`_get_cword`
cur=${cur///}
prev=${COMP_WORDS[COMP_CWORD-1]}
+ _split_longopt && split=true
+
+ if [[ "$prev" == --reference ]]; then
+ _filedir
+ return 0
+ fi
+
+ $split && return 0
+
# options completion
if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W '-c -h -f -R -v --changes \
--dereference --no-dereference --silent --quiet \
- --reference= --recursive --verbose --help --version' -- $cur ) )
+ --reference --recursive --verbose --help --version' -- $cur ) )
return 0
fi
@@ -4242,25 +4284,26 @@ complete -F _psql $default psql
_longopt()
{
- local cur opt
+ local cur prev
cur=`_get_cword`
+ prev=${COMP_WORDS[COMP_CWORD-1]}
- if [[ "$cur" == --*=* ]]; then
- opt=${cur%%=*}
- # cut backslash that gets inserted before '=' sign
- opt=${opt%\\*}
- cur=${cur#*=}
- _filedir
- # FIXME: see #297065... adding "-o nospace" (or $nospace),
- # should do the trick, but seems not working... ideas?
- COMPREPLY=( $( compgen -P "$opt=" -W '${comprep...@]}' -- $cur))
+ if _split_longopt; then
+ case "$prev" in
+ *[Dd][Ii][Rr]*)
+_filedir -d
+;;
+ *[Ff][Ii][Ll][Ee]*)
+_filedir
+;;
+ esac
return 0
fi
if [[ "$cur" == -* ]]; then
COMPREPLY=( $( $1 --help 2>&1 | sed -e '/--/!d' \
--e 's/.*\(--[-A-Za-z0-9]\+=\?\).*/\1/' | \
+-e 's/.*\(--[-A-Za-z0-9]\+\).*/\1/' | \
command grep "^$cur" | sort -u ) )
elif [[ "$1" == rmdir ]]; then
_filedir -d
@@ -6793,82 +6836,69 @@ _aspell_dictionary()
_aspell()
{
- local cur prev
+ local cur prev split=false
COMPREPLY=()
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
- # --name value style option
+ _split_longopt && split=true
+
case "$prev" in
- @(-c|-p|check))
+ -c|-p|check|--@(conf|personal|repl|per-conf))
_filedir
return 0
;;
- @(dump|create|merge))
+ --@(conf-dir|data-dir|dict-dir|home-dir|local-data-dir|pre
Re: [Bash-completion-devel] RFC: Better long option with argument completion
On Monday 13 April 2009, David Paleino wrote:
> On Mon, 13 Apr 2009 14:23:09 +0300, Ville Skyttä wrote:
> The patch looks good to me, just one *curiosity* (i.e. only curiosity,
> nothing to fix :P): why are you quoting
>
> + prev="${cur%%?(\\)=*}"
> + cur="${cur#*=}"
>
> ?
No particular reason, just a habit and general paranoia when working with
shell code that I can't shake even when working with strict bash only code ;)
> I'm in favour of *always* quoting things, just to be safe, but was just
> curious if there was a specific reason here.
I'm actually in slightly favour of not quoting when it's known that quoting
isn't needed, keeps things slightly more readable. But no strong opinions
here.
> I never found a longopt with embedded space :)
I have seen some whose values contain spaces, but anyway I don't think it'd
matter in bash (this is with 3.2.39(1)-release), I think the braces are enough
for it to grok what's going on:
$ cur="--foo=bar quux"
+ cur='--foo=bar quux'
$ prev=${cur%%?(\\)=*}
+ prev=--foo
$ cur=${cur#*=}
+ cur='bar quux'
$ cur="--foo bar=quux"
+ cur='--foo bar=quux'
$ prev=${cur%%?(\\)=*}
+ prev='--foo bar'
$ cur=${cur#*=}
+ cur=quux
> > Comments? I would like to commit _split_longopt soon and start changing
> > existing completions to use it.
>
> I'm fully in favour of it.
Cool.
> As soon as you'll commit the patch (if there are no other objections), I'll
> start fixing completions too. :)
Ok, will wait until tomorrow to see if there are other opinions.
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] mount label|uuid
On Sunday 12 April 2009, gibbo...@gmail.com wrote:
> COMPREPLY=( $( sed -n "/UUID/s/^UUID=\($cur[0-9a-f-]\{,36\}\).*/\1/Ip"
/etc/fstab ) )
I think this would be better put as:
COMPREPLY=( $( compgen -W '$( sed -ne "s/^UUID=\([^[:space:]]*\).*/\1/p"
/etc/fstab )' -- $cur ) )
"compgen -W ... -- $cur" is safer against unusual characters in $cur, and "I"
in sed's s///I only works with GNU sed as far as I know.
> COMPREPLY=( $( sed -n "/LABEL/s/^LABEL=\($cur[0-9a-z_]*\).*/\1/Ip"
/etc/fstab ) )
Ditto here:
COMPREPLY=( $( compgen -W '$( sed -ne "s/^LABEL=\([^[:space:]]*\).*/\1/p"
/etc/fstab )' -- $cur ) )
Could you test these changes and submit a new patch if they work for you?
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] mount label|uuid
On Tuesday 14 April 2009, gibbo...@gmail.com wrote: > Hi, > Modified as suggested, tested (but not "heavily") and it seems to work. [...] > - I postulated uuidgen always output lower-case hex Why make such assumptions and assumptions in general about the UUID length? Why not just look for whitespace like in the suggested: > > COMPREPLY=( $( compgen -W '$( sed -ne "s/^UUID=\([^[:space:]]*\).*/\1/p" > > /etc/fstab )' -- $cur ) ) Also, the leading /UUID/ seems to me as superfluous, i.e. why 'sed -ne /UUID/s/^UUID=.../p' instead of simply 'sed -ne s/UUID=.../p' ? (Ditto for LABEL.) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] mount label|uuid
On Tuesday 14 April 2009, gibbo...@gmail.com wrote: > On Tue, Apr 14, 2009 at 05:27:49PM +0300, Ville Skyttä wrote: > Also, the leading /UUID/ seems to me as superfluous, i.e. why 'sed -ne > > /UUID/s/^UUID=.../p' instead of simply 'sed -ne s/UUID=.../p' ? (Ditto > > for LABEL.) > > I always believed it was a performance gain as it will skip any line > without this pattern and never charge a buffer with more than 5 characters > of a non-matching line but I never did tests about that and it's maybe > a myth :[ Oh, ok. Anyway I would find it surprising if it was measurably different in this (/etc/fstab) case. > Also I removed the leading ^ as a fstab line mays begin with blank. > Last doubt : adding a leading ^[^#]* to the regexp as, in this world it may > exist some stupid fstab like : > #UUID=foo > /dev/sda1 > or > /dev/sda1 0 1 #UUID=blah > > I wish this attachment satisfactory :) Applied with minor changes (leading whitespace taken care of with ^[[:space:]]*, that takes care of comments as well). > A last thing : why the cygwin and solaris COMPREPLY don't use $(compgen -- > $cur) instead of $(grep "^$cur") ? A lot of things currently have that flaw, I have a patch in progress that fixes some of them. Patches obviously welcome ;). I also added a note about this in README's CONTRIBUTING section. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Style guide (was: Re: [SCM] bash-completion branch, master, updated. 95cd673b5cbd5658cbf56a56a4113722aab92177)
On Tuesday 14 April 2009, David Paleino wrote:
> On Tue, 14 Apr 2009 18:24:23 +, Ville Skyttä wrote:
> > @@ -884,8 +885,14 @@ _mount()
> >
> > | grep "^$cur" ) )
> >
> > else
> > # probably Linux
> > - COMPREPLY=( $( awk '! /^[ \t]*#/ {if ($2 ~ /\//) print $2}' \
> > + if [ $prev = -L ]; then
> > [..]
> > + elif [ $prev = -U ]; then
> > + [..]
> > + else
> > + [..]
> > + fi
>
> Why not case..esac? :)
Yeah... why not :). Anyone want to write a style guide? Here's a start for a
table of contents, in no particular order:
- case/esac vs if
- simple matching vs extended globbing in case statements: -@(a|b)) vs -a|-b)
- [[ ]] vs [ ]
- indentation
- line wrapping
- quoting
- awk vs cut for simple cases
- $(...) vs `...`
- variable and function naming
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] RFC: Better long option with argument completion
On Monday 13 April 2009, Ville Skyttä wrote: > On Monday 13 April 2009, David Paleino wrote: > > > As soon as you'll commit the patch (if there are no other objections), > > I'll start fixing completions too. :) > > Ok, will wait until tomorrow to see if there are other opinions. Committed, will proceed with the few examples that were in the previous patch as separate commits. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. b33a1c7526696585e43f4f6d23b1d0d88d176b99
On Wednesday 15 April 2009, Freddy Vulto wrote: > The following commit has been merged in the master branch: > commit b33a1c7526696585e43f4f6d23b1d0d88d176b99 > Author: Freddy Vulto > Date: Wed Apr 15 22:19:26 2009 +0200 > > Added asciidoc files. [...] > diff --git a/doc/main.xml b/doc/main.xml > new file mode 100644 > index 000..ddf324a > --- /dev/null > +++ b/doc/main.xml > @@ -0,0 +1,151 @@ > + [...] Hmm, should main.xml be in git at all? Isn't it generated from the *.txt files? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Style guide (was: Re: [SCM] bash-completion branch, master, updated. 95cd673b5cbd5658cbf56a56a4113722aab92177)
On Wednesday 15 April 2009, Freddy Vulto wrote: > On Tue, Apr 14, 2009 at 8:50 PM, Ville Skyttä wrote: > > Yeah... why not :). Anyone want to write a style guide? Here's a start > > for a table of contents, in no particular order: > > I'm in the process of writing documentation for the test suite and I'd > like to propose using asciidoc: http://www.methods.co.nz/asciidoc/ for > all bash completion documentation. This is my first experience with asciidoc (tried 8.4.3), and I must say I'm not too impressed. Does this mean one needs to know the DocBook DTD and be able to write the docs in a asciidoc/plaintext format that kind of conforms to the DTD, instead of asciidoc just taking care of that stuff? If so, doesn't sound too interesting. $ ./makeHtml.sh ./main.xml:18: element preface: validity error : Element preface content does not follow the DTD, expecting (beginpage? , prefaceinfo? , (title, subtitle? , titleabbrev?) , (toc | lot | index | glossary | bibliography)* , tocchap? , (((calloutlist | glosslist | bibliolist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset| task | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+ , (sect1* | refentry* | simplesect* | section*)) | sect1+ | refentry+ | simplesect+ | section+) , (toc | lot | index | glossary | bibliography)*), got (title ) ^ ./main.xml:23: element part: validity error : Element part content does not follow the DTD, expecting (beginpage? , partinfo? , (title , subtitle? , titleabbrev?) , partintro? , (appendix | chapter | toc | lot | index | glossary | bibliography | article | preface | refentry | reference)+), got (title simpara simpara ) ^ a2x: failed: xmllint --nonet --noout --valid "./main.xml" ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Spam on this list
Hello, There seems to be some spam coming through to this list. Is the list subscribers-can-post-only? If not, why not? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [mplayer] Add .ape and sort extensions.
On Sunday 10 May 2009, Santiago M. Mola wrote: > Hi all, > > I'm attaching a couple of small patches for mplayer completion. > > 0001-Add-.ape-to-mplayer-supported-extensions.patch > 0002--mplayer-Sort-and-remove-redundancy-on-extensions.patch These patches seem somewhat outdated, .ape has already been added and mplayer completion split to contrib/mplayer in git master. Please check if any of the changes are still applicable to git master and submit new patches if so. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Sunday 17 May 2009, Guillaume Rousse wrote: > Hello list. > > According to our roadmap, > http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still > have to finish splitting completions in individual files, and also to > review existing completions. I did a first pass on first task, Entries for these changes seem to be missing from CHANGES and Makefile.am, please add them. > but as > the second mostly concerns completions I submitted myself, I'd like > someone else to do it :P Well, as I suggested earlier, I think post-commit rather than pre-commit reviews would be a better process for bash-completion. I have some completions stuck in to_review/ as well. Now that the completions under review are committed in to_review/, those terms no longer capture too well what I meant, so here's another proposal: completions that have been in to_review/ for two weeks or more without pending TODO items (i.e. if all issues pointed out by reviewers have been sorted out or if nobody has posted any review comments) may be moved to contrib/ by their submitter without explicit review pass notice if the submitter considers them ready for general consumption. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 4fadb6887aa48cb4b835209a2733010f5f94c3cb
On Wednesday 20 May 2009, David Paleino wrote: > The following commit has been merged in the master branch: > commit 4fadb6887aa48cb4b835209a2733010f5f94c3cb > Author: David Paleino > Date: Wed May 20 22:08:53 2009 +0200 > > Fix checks for GNUish userland, thanks to Robert Millan (Debian: > #529510) Shouldnt USERLAND be unset at the end of bash_completion when it's no longer needed like other such variables? Spelling it in lowercase might also make it clearer that it's not a global variable that should persist. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [SCM] bash-completion branch, master, updated. 65d9348f3e5a31adf38ace19a3c1d4e6a302fe9e
On Saturday 23 May 2009, David Paleino wrote: > Hello, > > On Sat, 23 May 2009 08:45:49 +0000, Ville Skyttä wrote: > > The following commit has been merged in the master branch: > > commit 65d9348f3e5a31adf38ace19a3c1d4e6a302fe9e > > Author: Ville Skyttä > > Date: Sat May 23 11:45:39 2009 +0300 > > > > Fix man completion (was broken by recent $UNAME/$USERLAND changes). > > How was that broken? > man(1) completion is working here, and I haven't yet pulled this commit. $USERLAND is not set inside _man() when it runs (and it shouldn't be): $ man + local cur prev sect manpath manext mansect UNAME + manext='@([0-9lnp]|[0-9][px]|man)?(.@(gz|bz2|lzma))' + mansect='@([0-9lnp]|[0-9][px])' + COMPREPLY=() ++ _get_cword ++ [[ 0 -eq 0 ]] ++ printf %s '' + cur= + prev=man + [[ man == -l ]] + _expand + [[ '' == \~*/* ]] + [[ '' == \~* ]] + [[ '' == */* ]] ++ uname -s + UNAME=Linux + UNAME=Linux + '[' = GNU -o Linux = FreeBSD -o Linux = Cygwin ']' bash: [: too many arguments It could be that it worked before USERLAND was unset at the end of bash_completion by another commit which I requested, perhaps you weren't running with a version that had that commit applied? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [SCM] bash-completion branch, master, updated. 65d9348f3e5a31adf38ace19a3c1d4e6a302fe9e
On Sunday 24 May 2009, David Paleino wrote: > $ grep BASH .bash* > .bashrc:export BASH_COMPLETION=/deb/git/bash-completion/bash_completion > .bashrc:export BASH_COMPLETION_DIR=/deb/git/bash-completion/contrib Hmm, interesting, I should set up something like that for myself too. But how does that work; do you have another line somewhere in your profile which sources $BASH_COMPLETION that you set in the above? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Non-filename completions containing slashes and -o filenames
Hello,
I'm trying to figure out how to do the right thing with non-filename
completions containing slashes in a function that was passed to complete along
with -o filenames.
For example:
_foo()
{
COMPREPLY=( $( compgen -W 'a/b c/d e/f/g' -- ${COMP_WORDS[COMP_CWORD]} ) )
}
complete -F _foo -o filenames foo
a/b, c/d and e/f/g are *not* file/path names but other completions that just
happen to contain slashes. Whenever I wan't some of them, I don't want
file/dirname completion.
If I leave things as is in the above, "foo " displays "b d g" whereas
I'd want "a/b c/d e/f/g" displayed _but_ for example "foo a" properly
completes to "foo a/b " nevertheless. So it's just the display of available
completions that is wrong (everything up to and including the last slash is
missing).
If I remove "-o filenames", this simple example works as expected. But in
real life _foo() is not that simple and in many cases within it filename
completion is desired so it can't just be removed. I tried "compopt +o
filenames" with bash 4.x inside _foo() but that didn't help.
Ideas?
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] xsltproc completion
On Monday 25 May 2009, Raph wrote: > Hello, > a quick attempt to make the > completion of xsltproc. > See attachement. [...] > --encoding) > COMPREPLY=( $(compgen -W "$(localedef --list-archive)" -- "$cur" )) On a very brief look [0], this doesn't seem right to me. localedef --list- archive returns quite a bit of other things than character encodings at least on my Fedora 10 box: $ localedef --list-archive | head -n 10 aa_DJ aa_DJ.iso88591 aa_DJ.utf8 aa_ER aa_ER.utf8 aa_er.u...@saaho aa...@saaho aa_ET aa_ET.utf8 af_ZA ...and localedef seems to be something entirely different on Solaris. locale -a would seem more portable (if it is the right tool for this job in the first place; perhaps iconv -l would be better). [0] IMHO contributions that are more than a few lines of trivial patches are less likely to fall through the cracks if they're submitted in the alioth tracker rather than posted here... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Mail from Debian BTS
Hello, I find the amount of mail originating from the Debian BTS to this list quite excessive. For example, I've received at least 9 mails about Debian bug 531337 yesterday/today, some of which are pretty much gibberish to me (some kind of machine generated processing reports), and others look pretty much like duplicates. One mail would have been enough, and I'm not sure if even that is necessary; no other distro BTS does that either. Is there a way to at least decrease the amount of the Debian BTS mail, if getting rid of it altogether on this list is not found desirable by others? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] unalias sed? (was: Re: [Bash-completion-commits] [SCM] bash-completion branch, master, updated. b14fdb74b3b7fd7a707bc2afea55c10ea521d4f0)
On Friday 05 June 2009, David Paleino wrote: Hi David, > The following commit has been merged in the master branch: > commit 6170eb0001510426ccc7461e60e46c68992bcd14 > Author: David Paleino > Date: Fri Jun 5 08:13:46 2009 +0200 > > Don't assume "sed" being GNU sed, use "gsed" whenever available > (Debian: #501479, Alioth: #311393) [...] > @@ -3673,3 +3673,6 @@ unset UNAME USERLAND default dirnames filenames have > nospace bashdefault plusdir > > set $BASH_COMPLETION_ORIGINAL_V_VALUE > unset BASH_COMPLETION_ORIGINAL_V_VALUE > + > +# remove aliases we set earlier > +unalias sed Like I explained in Alioth #311393, I believe the unalias here is wrong - it results in our aliased sed being in effect only for the duration of reading bash_completion and the split files, not at runtime when sed gets actually invoked and we for now want it to cope with GNU sed extensions. Did I miss something? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Dropping _subversion (was: Re: [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 81e48606d011a96393ae2ae713bc6cda0fb18249)
On Friday 05 June 2009, Guillaume Rousse wrote: > David Paleino a écrit : > > The following commit has been merged in the master branch: > > commit 81e48606d011a96393ae2ae713bc6cda0fb18249 > > Author: David Paleino > > Date: Fri Jun 5 08:30:26 2009 +0200 > > > > Don't install _subversion anymore > > Which means it isn't distributed either... I'd prefer to keep it > available in the archive. What's the reason for not installing it anyway? If there is a good one, I think it should at least be mentioned in the change log. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Dropping _subversion (was: Re: [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 81e48606d011a96393ae2ae713bc6cda0fb18249)
On Friday 05 June 2009, David Paleino wrote: > On Fri, 5 Jun 2009 18:47:18 +0300, Ville Skyttä wrote: > > On Friday 05 June 2009, Guillaume Rousse wrote: > > > David Paleino a écrit : > > > > The following commit has been merged in the master branch: > > > > commit 81e48606d011a96393ae2ae713bc6cda0fb18249 > > > > Author: David Paleino > > > > Date: Fri Jun 5 08:30:26 2009 +0200 > > > > > > > > Don't install _subversion anymore > > > > > > Which means it isn't distributed either... I'd prefer to keep it > > > available in the archive. > > > > What's the reason for not installing it anyway? If there is a good one, > > I think it should at least be mentioned in the change log. > > Didn't we agree that upstream one was better than our? Wasn't that also the > reason to install it as "_subversion", i.e. to avoid filename collision > with upstream's? I don't recall any of that, perhaps I wasn't yet following upstream bash- completion when that was discussed [0]. And I'm certain a lot of bash- completion users don't do that either, therefore this information would be very good to have in CHANGES to avoid confusion (that's what I did when I removed hg). > Anyway, we could also revert that commit, no hard feelings about it. Like Guillaume, I'd prefer if it was kept around in the dist tarball for a while even if not installed by default. Add it to EXTRA_DIST in Makefile.am? [0] Actually I've several times had the intention to ask why it was named _subversion with the underscore but never did; anyway now I know ;) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] unalias sed? (was: Re: [Bash-completion-commits] [SCM] bash-completion branch, master, updated. b14fdb74b3b7fd7a707bc2afea55c10ea521d4f0)
On Friday 05 June 2009, David Paleino wrote: > On Fri, 5 Jun 2009 18:41:07 +0300, Ville Skyttä wrote: > > On Friday 05 June 2009, David Paleino wrote: > > > @@ -3673,3 +3673,6 @@ unset UNAME USERLAND default dirnames filenames > > > have nospace bashdefault plusdir > > > > > > set $BASH_COMPLETION_ORIGINAL_V_VALUE > > > unset BASH_COMPLETION_ORIGINAL_V_VALUE > > > + > > > +# remove aliases we set earlier > > > +unalias sed > > > > Like I explained in Alioth #311393, I believe the unalias here is wrong - > > it results in our aliased sed being in effect only for the duration of > > reading bash_completion and the split files, not at runtime when sed gets > > actually invoked and we for now want it to cope with GNU sed extensions. > > Ok, good. > What about: > > alias mysed=sed > have gsed && alias mysed=gsed > > ? > > (we can obviously change "mysed" to something else, it's just to clarify > the solution) If we go down that route, does the alias buy us anything over a usual shell variable? For example have gsed && _bashcomp_sed=gsed || _bashcomp_sed=sed ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Monday 08 June 2009, Guillaume Rousse wrote: > Guillaume Rousse a écrit : > > Hello list. > > > > According to our roadmap, > > http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still > > have to finish splitting completions in individual files, and also to > > review existing completions. > > We finished 2.b (rewieving), and we almost finished 2.a (splitting). We > just have the following completions to split: > - freebsd kldload and kldunload > - freebsd portinstall and portupgrade > - slackware removepkg > - look -> contrib/util-linux-ng > - id -> contrib/coreutils > > I'd like to finish it, but I don't know how to name the file for the > fist ones... I dug up some info from http://www.freshports.org/ and http://packages.slackware.it/ and split the FreeBSD and Slackware things based on those findings. Go ahead with "look" and "id" when you feel like it. > On our agenda, the point 3 is to merge bash-completion-lib's test suite. > However, I feel like it's gonna take some time, and will only concerns a > few people here. I'd rather have a release right now (bash-completion > 2.0), and insert into our calendar shorter developement steps: > - drop bash 2.0 compatibility stuff > - adopt a new setup (installing stuff somewhere, parsing them elsewhere) > - adopt a new syntax policy (I really feel tab-based indentation is way > to cumbersome, see contrib/openssl for instance) > > Basically, it means re-ordering points 3, 4 and 5 in our current > roadmap, and expanding point 5. I have no problems with this plan (although I have a pile of fairly innocent patches that I'd like to see go in the next release, more on that in a separate mail). But the test suite sure would be nice to have, and I have no idea how much work adopting that would be - if not too long, stick with the plan to include it in the next release. Freddy? Regarding syntax/indentation policy, I think it'd be good to just do a poll like with the SCM choice. David? (Can't help plugging my favourite here, sorry ;): indent step 4, tab width 8, mixed spaces/tabs; or indent step 4, spaces only.) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Patches for review (bluez-utils, heimdal, mailman, reportbug, vpnc, wireless-tools)
Hello, Like mentioned in the roadmap thread, I have a small pile of patches needing review: bluez-utils, heimdal, mailman, reportbug, vpnc, wireless-tools: http://scop.fedorapeople.org/patches/bash-completion/ I don't really use these commands myself, so the patches are basically untested. They're quite innocent though, mainly adding use of _split_longopt (note: not even tested whether the affected commands actually work with "--foo bar" as well as "--foo=bar") and protection against unusual input using compgen -W, added "have foo"s and the like. Let me know if you've tested and had success with some of these and I'll go ahead and apply to master. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 8270b9cf81f3931051518d13f46d7ee6c87969eb
On Tuesday 09 June 2009, Guillaume Rousse wrote: > Ville Skyttä a écrit : > > The following commit has been merged in the master branch: > > commit 696ee59f7e20907805a18d99e6a00ae95f91d149 > > Author: Ville Skyttä > > Date: Tue Jun 9 00:18:27 2009 +0300 > > > > Note 'have foo' additions. > > > > diff --git a/CHANGES b/CHANGES > > index fb658ed..96ccdf0 100644 > > --- a/CHANGES > > +++ b/CHANGES > > @@ -88,6 +88,8 @@ bash-completion (1.x) > >* Split FreeBSD portupgrade and friends completion to > > contrib/portupgrade. * Split Slackware pkgtools completion to > > contrib/pkgtools. > >* Improve rpm group completion (displayed completions are still > > wrong). + * Change many completions to install only if the completed > > commands are +available. > > The wording is misleading: I'd say 'to load in memory', instead of 'to > install'. So far, we install everything on the disk in a directory whose > whole content is automatically sourced by main code, when running make > install. Works for me, feel free to fix it. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Patches for review (bluez-utils, heimdal, mailman, reportbug, vpnc, wireless-tools)
On Thursday 11 June 2009, Guillaume Rousse wrote: > Ville Skyttä a écrit : > > Let me know if you've tested and had success with some of these and I'll > > go ahead and apply to master. > > They'll look OK for me. As I also prefer to test them by daily usage, > feel free to commit them. Done, thanks for taking a look. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] hostname completion issues
Hello, Some recent changes (known hosts stuff?) have broken ssh hostname completion quite badly for me in git master. First, "ssh " completes to an insane amount (almost 3500) things, apparently including all shell functions and builtins I have around, every command in path, and hostnames from my known_hosts files. Second, hostname completions never seem to get filtered at all. Let's say I want to ssh to git.debian.org: $ ssh gi Display all 321 possibilities? (y or n) $ ssh git Display all 310 possibilities? (y or n) $ ssh git.debi Display all 179 possibilities? (y or n) $ ssh git.debian.org Display all 179 possibilities? (y or n) Nope, I don't have 179 entries starting with git.debian.org in my known_hosts files, I have 1: git.debian.org. By looking at those 179 possibilities, the list seems to contain all hostname completions available, so it never reduces that set based on what I've typed. This is with bash 3.2.39(1)-release. Anyone else seeing this? Anyone working on known hosts completion? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 976fafa07e57f1e0085c08c55d7453098197fe98
On Saturday 20 June 2009, David Paleino wrote: > diff --git a/bash_completion b/bash_completion > index e56b871..2b7e589 100644 > --- a/bash_completion > +++ b/bash_completion > @@ -1197,7 +1197,7 @@ _known_hosts_real() > # Add hosts reported by avahi, if it's available > # and if the daemon is started. > if type avahi-browse >&/dev/null; then > -if [ -z "$(pidof avahi-daemon)" ]; then > +if [ -n "$(pidof avahi-daemon)" ]; then "pidof" is not in non-root users' default $PATH in many systems, for example Red Hat/Fedora ones (it's in /sbin there which is not in default $PATH until in recent Fedora releases I suppose), so this won't work properly on those. Add /sbin to a local $PATH and/or redirect stderr to /dev/null when running it? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#536815: postgresql-client-8.3: local db tab completion for psql
On Tuesday 14 July 2009, Faheem Mitha wrote: > If there is a Ubuntu bug or a discussion in > the ML is would have been helpful to link to it. For one thing, is would > make requests like this less likely. First two distinct hits when Googling "ubuntu psql completion": http://ubuntuforums.org/showthread.php?t=613499 https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/164772 Disclaimer: I have nothing to do with Ubuntu or Debian nor have a strong opinion on the issue - the argument in the Ubuntu bug tracker seems quite valid to me though. I've added a pointer to that bug in sources and CHANGES in git. > Otherwise, is there some way to reenable this functionality locally? See the _pg_databases and _pg_users completion functions. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] hostname completion issues
On Saturday 25 July 2009, Guillaume Rousse wrote: > I like the idea, but using stdout for output would force to use > subshells to get the result. [...] > I guess there would be additional overhead added. It would also require the caller to take care of $IFS stuff, whereas if adding directly to an array, functions can take care of that internally as appropriate. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _filedir only escaping whitespace when `-o filenames' is in effect?
On Tuesday 28 July 2009, Freddy Vulto wrote: > I was under the assumption that `_filedir' was to be trusted > anywhere, but it seems it isn't or am I overlooking something? I think it isn't... > Otherwise, wouldn't it be nice to add an option to `_filedir' to > escape spaces? Or better, create a new function `_compgen_filedir' > with this optional behaviour ;-)? ...but why wouldn't simply adding $filenames to their "complete" calls be the right thing to do? The above sounds somewhat messy to me and personally I'd rather start thinking about getting rid of most of _filedir's current contents (when we can assume -o plusdirs) than adding more hair that duplicates existing functionality to it. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#540033: Bug#540033: bash-completion: xine (and probably other video players) doesn't complete ogv files
On Wednesday 05 August 2009, Gerfried Fuchs wrote: > Please also add ogv to the supported files that xine (and most probably > also other video players) complete. Added in upstream git for xine and friends, mplayer already had it. http://git.debian.org/?p=bash-completion/bash- completion.git;a=commit;h=dcc30c7 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _filedir only escaping whitespace when `-o filenames' is in effect?
On Monday 03 August 2009, Freddy Vulto wrote: > I don't see how `-o plusdirs' is going to save us here? It probably doesn't - I just mentioned it in a context where I suggested current _filedir would be pretty much obsolete if we could assume -o plusdirs could be used everywhere. > So I think our only options are to wait for bash-4 or to fix > _filedir working correctly also if `-o filenames' isn't in effect. I don't think we need to wait for bash 4, we can already start using $compopt (see the patch I just committed). It won't do any good (nor harm) for bash < 4 users, but leaving things as they are w.r.t. $filenames (and other similar things) and sprinkling $compopt for bash >= 4 users' pleasure where appropriate would be the approach I'd personally look into. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#544024: Completion with backslashes broken
On Thursday 03 September 2009, Norbert Preining wrote:
> On Do, 03 Sep 2009, EspeonEefi wrote:
> > --- /etc/bash_completion.orig 2009-09-03 08:21:15.229720217 -0400
> > +++ /etc/bash_completion2009-09-03 08:21:36.473719600 -0400
> > @@ -213,6 +213,10 @@
> > # results in the original argument
> > quote_readline()
> > {
> > + if [ ${BASH_VERSINFO[0]} -gt 3 ]; then
> > + echo "$1"
> > + return
> > + fi
> > local t="${1//\\/}"
> > echo \'${t//\'/\'\\\'\'}\' #'# Help vim syntax highlighting
> > }
>
> Thanks, that at least fixed the problem for me. I have added
> these 4 lines for now and hope for what upstream is doing.
Practically the same thing. There's just no release with this fix out yet.
http://git.debian.org/?p=bash-completion/bash-
completion.git;a=commitdiff;h=1421e55aac075e13491cd212b796bdd453214a2c
http://git.debian.org/?p=bash-completion/bash-
completion.git;a=commitdiff;h=4475d3634923de7a169c67aaa197f388bb418de8
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] scp remote path completion broken?
Hello, scp's remote path completion appears broken to me - the ":" to _get_cword does not seem to affect anything and thus the hostname always disappears and things go south from there. On a brief look, it seems to me that _get_cword doesn't actually do anything with the argument given to it. This is on Fedora 11, bash 4.0.23. Did I overlook something? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
On Sunday 06 September 2009, Freddy Vulto wrote: > On Fri, Sep 4, 2009 at 11:50 PM, Ville Skyttä wrote: > > scp's remote path completion appears broken to me - the ":" to _get_cword > > does not seem to affect anything and thus the hostname always disappears > > and things go south from there. On a brief look, it seems to me that > > _get_cword doesn't actually do anything with the argument given to it. > > > > This is on Fedora 11, bash 4.0.23. Did I overlook something? > > I can confirm the same problem on Ubuntu, bash-4.0-28. Doh, I didn't remember I have already filed a bug for this earlier; it just only semi-recently started to actually bite here when I upgraded to Fedora 11. https://alioth.debian.org/tracker/index.php?func=detail&aid=311702&group_id=100114&atid=413095 If nobody can remember/decipher exactly what the problematic commit was supposed to fix, I suggest we just revert it and see what breaks. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Hardcoded /sbin/lsmod
On Thursday 18 June 2009, Mark Rosenstand wrote: > Hi, > > Sorry for not reporting this through the bug tracker, I'm a bit short on > time but thought this is trivial enough to fix through a simple mail. It apparently wasn't at the time, but by chance I still happened to have this mail around. > The path to lsmod seems to be hardcoded in 1.0 and git, making > modprobe -r completion bomb out on my system with a vanilla > module-init-tools 3.9 (./configure --prefix=/usr --exec-prefix=) Should be fixed in http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=b5505959afd6744e6d09c4a4b1a888d118aa9063 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#545743: Bug#545743: bash-completion: sbcl completion and file/directory-name argument
On Tuesday 08 September 2009, Christophe Rhodes wrote: > A common operation for me is to type > ./srrusb --core ousb > expecting that to complete to > ./src/runtime/sbcl --core output/sbcl.core > > Unfortunately, the after "ou" in that command line doesn't perform > a partial complete to "output/", but (apparently) a full complete to > "output ", meaning that I end up with a command-line of > > ./src/runtime/sbcl --core output sbcl-pwd.sh I know nothing about sbcl, but could you try modifying /etc/bash_completion.d/sbcl, replacing complete -F _sbcl $default sbcl sbcl-mt with: complete -F _sbcl $filenames sbcl sbcl-mt and report back whether this fixes it for you. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 8e496adff30d29b7c240dfc90860eca8b6970ae7
On Monday 14 September 2009, Guillaume Rousse wrote: > The following commit has been merged in the master branch: > commit 8e496adff30d29b7c240dfc90860eca8b6970ae7 > Author: Guillaume Rousse > Date: Mon Sep 14 23:01:19 2009 +0200 > > initial import > > diff --git a/install-completions b/install-completions > new file mode 100755 > index 000..0a1a4ec > --- /dev/null > +++ b/install-completions Hmm, what's this? Some comments would be nice. Should it be also taken care of in Makefile.am? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 5b760a88bbddd2bd3647ebdc1235661a29ca0030
On Monday 14 September 2009, Guillaume Rousse wrote: > The following commit has been merged in the master branch: > commit 5b760a88bbddd2bd3647ebdc1235661a29ca0030 > Author: Guillaume Rousse > Date: Mon Sep 14 21:49:44 2009 +0200 > > add mdam and resolvconf completion to installed files list > > diff --git a/Makefile.am b/Makefile.am > index d23e51e..2e2aba2 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -73,6 +73,7 @@ bashcomp_DATA = contrib/ant \ > contrib/man \ > contrib/mc \ > contrib/mcrypt \ > + contrib/mdam \ s/mdam/mdadm/, no? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] New version 1.1 -- release date
On Tuesday 15 September 2009, Guillaume Rousse wrote: > David Paleino a écrit : > > Hello people, > > I'm having exams, so I can't really be of help in preparing a release for > > 1.1 *now*. I thought we can make a release on Sep 30/Oct 1 -- what's your > > opinion on this? > > According to the roadmap, there is still the indentation policy issue, > to decide and to apply. I don't know hot the get the result of the > survey on Alioth :) Oh, I didn't even know that there's one open. Anyway, submitted my .02€ now (and no, I don't know how to get the results either). > Otherwise, I'd be willing to help for the release, but I'm still not > confident enough with git for this. I can help out with this as well if needed. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 3a69bd3e9379f8092d4cb69f1f83fcfeb98aa537
On Thursday 17 September 2009, David Paleino wrote: > The following commit has been merged in the master branch: > commit f13ea4968bc11c69fb1f0cc88aa95dceb928ca56 > Author: David Paleino > Date: Thu Sep 17 22:15:13 2009 +0200 > > Avoid sed pipe as ps itself can omit the headers (thanks to Elan > Ruusamäe) [...] > - COMPREPLY=( $( compgen -W '$( command ps axo pid | sed 1d )' -- $cur ) ) > + COMPREPLY=( $( compgen -W '$( command ps axo pid= )' -- $cur ) ) [...] > - COMPREPLY=( $( compgen -W '$( command ps axo pgid | sed 1d )' -- $cur )) > + COMPREPLY=( $( compgen -W '$( command ps axo pgid= )' -- $cur )) [...] > - COMPREPLY=( $( compgen -W '$( command ps axo command | \ > -sed -e "1d; s/ .*//; s:.*/::; s/:$//;" \ > + COMPREPLY=( $( compgen -W '$( command ps axo command= | \ > +sed -e "s/ .*//; s:.*/::; s/:$//;" \ When I last worked on these, IIRC I found some systems where the "=" suffix like in the above didn't work. It could have been a Tru64 box, but unfortunately I don't have access to one any more to check. Just a FYI in case someone runs into problems with this later. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Mail spam trapped by gmail
Hello, just a FYI, I noticed that people are replying to messages on bash-completion-devel that I had not seen at all, which led me to check my gmail spam folder. I found 20+ bash-completion-devel messages there, practically all of which were from David. So if some others here are using gmail as well, it might be a good idea to do "in:spam paleino" and "in:spam bash-completion" searches... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [RFC] Completions location
On Sunday 20 September 2009, Guillaume Rousse wrote: > David Paleino a écrit : > > Hello, > > I remember we decided to push all completions to respective upstreams, > > but didn't decide anything more than that, at the time. -- or it could've > > been a joke of my mind :) > > > > On IRC the discussion was raised by the maintainer of the PLD package. He > > has a few points, which I believe we already discussed about, with some > > new features: > > > > 1) upstreams won't possibly handle completions like we can -- be it > >syntactically, stylistically, functionally; I don't think syntactic or stylistic issues are anything to be concerned about. Regarding functionality, I don't think it would be impossible for upstreams to do practically as good job as we (or even better), but we should make it easier for them: define a stable well documented API they can count on being available and not change. This would consist of both functions and completion snippet dir location stability (perhaps a pkg-config file or something for the latter would be a good idea). When completions are included/installed from upstream packages, there is room for improvements that we can't as easily do, which I believe in the long run can result in _better_ functionality/performance/end user experience than we can provide: - No need to do any have() or trigger games, when installed with rest of the upstream software, it is known that the completed commands are there. - No need to keep completion stuff for old versions of the software around nor try to be careful or do guesses what the commands might look in the future: just keep it up to date with the released version - it doesn't have to work with anything else except that. We on the other hand should provide documented and stable helpers that work regardless of (supported) bash version and to the extent possible, across operating systems. > > 2) we would lose maintainance of the completions. Frankly, I think this would be a good trend ;) > > Or, if we want to keep > > it, it would be a nightmare: we would need a $vcs write access for the > > completion for each software package. A mess. Nah, these should be exceptional cases. If someone wants to maintain something upstream, by all means do it, but there should be no actual requirement for this. > > 3) bash-completion will rapidly decrease in performance, because of > > probably poorly written code. I don't buy this. > For the last issue, which is to distribute in a single package, and > activate only when needed, I initially attempted to use triggers too. > However, we now have 175 various completions in contrib directories, > meaning 175 * 2 triggers (installation/uninstallation) to maintain, > keeping track of the various mismatch between package names and > completion file name. All in all, that's just impossible. This is surely a bit (yep, a bit, not a lot) of work, but why would it be impossible? I haven't packaged post 1.0 bash-completion for Fedora but I do for now intend to continue with the trigger approach. With a few helper macros I think it's quite manageable, see http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash- completion.spec?revision=1.42&view=markup > The intent of the script I recently commited in the project > (install-completions), is to leverage this problem, I'll however intend to look into this script as well. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
On Sunday 20 September 2009, Freddy Vulto wrote: > bash-4 now uses __get_cword4() which should solve scp's remote path > completion on bash-4. Seems to work again indeed, thanks! ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Patch review needed
On Friday 18 September 2009, Guillaume Rousse wrote: > David Paleino a écrit : > > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/bash-completion/bash > >-completion-rpm-cache.patch [...] > > The patches actually changes 3 things: > 1) it uses an additional /var/cache/hrmib, which seems to be jbj-version > specific, if available > 2) it forces refreshing the dumped package list if writable > 3) it changes the format of completed package names ...and a 4th, it removes the "ver" local variable, which I believe is fine as it seems unused. > 1 and 3 are OK for me. > > I'm more reserved about 2, tough. /var/log/rpmpkgs is not really a bash > completion specific file, rather some daily dump of the package > database. I don't think it really hurt to rebuild it, but so far > completions never changed the system state. Anyway, this cache > refreshing should only occurs if cache is outdated (in the else part of > the last test), not everytime you complete on package list. I think 1) and 4) are ok, although I have no clue about 1). But before 3) is done, I don't think 1) can be applied as is. I do object to 2). This is changing the system state, and screws existing functionality if people rely on diffing various rotated /var/log/rpmpkgs* files to see what packages have been removed/installed/updated between log rotations. /var/log/rpmpkgs is created by /etc/cron.daily/rpm daily at least on Fedora and CentOS. Caching the info somewhere else would be fine with me though (e.g. /var/cache/bash-completion/rpmpkgs), but /var/log/rpmpkgs should not be mucked with. I also have some reservations about 3). _rpm_installed_packages is used at least by apt in bash-completion, as well as rpmlint and rpmdevtools (both upstream, not in bash-completion) completions, and I'm not at all sure they all handle the name-version-release.arch format. And I'm not sure if that format buys us much at all - I do see the value in name.arch but the rest seem pretty much just noise to me (and if one wants it to be as complete as possible, the format is missing epoch, BTW). So I would suggest starting with applying 4) and 1), with 1) modified so that it works on plain package names. Then, with more testing perhaps apply 3) later (but I'm inclined to use name.arch for it only), and maybe use a different function name than _rpm_installed_packages or args for it in order to not screw existing completions out there. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Patch review needed
On Monday 21 September 2009, Elan Ruusamäe wrote:
> On Monday 21 September 2009 00:35:38 Ville Skyttä wrote:
> > I also have some reservations about 3). _rpm_installed_packages is used
> > at least by apt in bash-completion, as well as rpmlint and rpmdevtools
> > (both upstream, not in bash-completion) completions, and I'm not at all
> > sure they all handle the name-version-release.arch format. And I'm not
> > sure if that format buys us much at all - I do see the value in name.arch
> > but the rest seem pretty much just noise to me
>
> why not check that the other tools can handle complete match?
It's impossible to check everything out there, because we simply can't know
what exists and relies on the current behavior; I just listed a few I know of.
Therefore I strongly think that the behavior shouldn't be simply silently
changed, it either needs to be done by adding a new function that returns
things with the different format, or adding a parameter that triggers the new
format, or if everything else fails by prominently documenting the backwards
incompatible change in release notes.
> i suppose
> they all eventually route the query to rpm itself, which can handle
> complete or partial matches...
Some do, some don't. Some of the ones I mentioned (for example rpmlint) feed
their arguments to rpm's python bindings which don't work like that; code
changes are needed.
> as for the nvra matches, if you have several versions of package installed,
> then tab complete should be able to give exact package names which to
> uninstall. adding only .arch would make result still ambigious (in case you
> have two versions of same %{name} installed from same %{arch}).
>
> having two versions installed is quite common if you run rpm upgrade and
> old package %postun fails with an error. or if you want to rpm -i/-e some
> kernel package.
kernel is a good point, that's not at all uncommon.
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [RFC] Completions location
On Tuesday 22 September 2009, Elan Ruusamäe wrote: > On Monday 21 September 2009 22:36:18 Guillaume Rousse wrote: > > Ville Skyttä a écrit : > > > http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash- > > > completion.spec?revision=1.42&view=markup > > > > Interesting. Maybe a bit of lua scripting could help also here. > > same (similar) approach already in pld linux package, from which the thread > started: > > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/bash-completion/bash-c > ompletion.spec?rev=1.153;content-type=text/x-cvsweb-markup Ah yes, I had forgotten about that approach - I used practically that one some 4 years ago in Fedora but later reverted to the slightly clumsier approach currently employed in order to make the package buildable with older rpm versions in RHEL with which I couldn't get %bashcomp_trigger macro definition to work. Glad to see others found use for it, and I should probably see if I could revert back to it these days again. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] RFC: complete only long options where they exist and work
Hello,
I'd like to suggest that when we complete available options, we'd generally
offer only the long options as completions if an option has a short
option/alias/other counterpart and if it is known that the long option works
well enough (basically if the long option takes no arguments, or takes an
argument that can be separated with space (not only "=", but possibly both),
it is ok). For example, if let's say -f, -F, and --foo are equivalent, we
offer only --foo out of them when $cur = -*.
My rationale is that it results in fewer suggestions and thus more streamlined
operation (sometimes no suggestions but direct completion), and that whenever
it results in more than one completion, the user is more likely to be able to
choose what she wants from the set of possible long descriptive options than
short ones or a mixture of them.
Note that we should still do option argument and other processing based on all
the options given to the extent we can, even if they are the short ones, just
like we do now - we'd just not generally list anything but long options that
meet the above criteria and obviously short ones for which no corresponding
long one exists.
For example, let's say if command foo takes -s, -S and --something all of
which do the same thing, we list only --something when listing possible -*
completions, but if that option takes an argument, we complete the possible
arguments for all variants.
Simplified semi-pseudocode example: instead of doing:
foo ()
{
case $prev in
-s|-S|--something)
do_something
return 0
;;
esac
if [ $cur = "-*" ] ; then
COMPREPLY=( $( compgen -W '-s -S --something' -- "$cur" ) )
fi
}
...we'd do:
foo ()
{
case $prev in
-s|-S|--something)
do_something
return 0
;;
esac
if [ $cur = "-*" ] ; then
COMPREPLY=( $( compgen -W '--something' -- "$cur" ) )
fi
}
(so the only difference is the COMPREPLY=... line).
Thoughts?
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
