Skip to main content

bash - Tab completion for command arguments fail in Cygwin due to `.exe` extension


Is there a configuration option in Cygwin so that when Bash completes the name of the command, the filename’s .exe suffix is ignored (not included)?




Explanation of the problem


When using tab completion in Bash on a Cygwin system to complete the name of a command, the .exe extension is appended to the command name, e.g, typing opens and pressing Tab completes the command to openssl.exe.


The command runs fine (with MS Windows the .exe extension is optional when running a command) but the problem is that the _openssl() completion function provided by the bash-completion package is only configured to provide completions of arguments for openssl – not openssl.exe. For example:


$ complete -p openssl openssl.exe
complete -o default -F _openssl openssl
bash: complete: openssl.exe: no completion specification

The same issue exists when trying to complete arguments for all executable commands.


I currently use Bash with Emacs mode configured for Readline editing so I can press Esc followed by two Backspace presses to remove the .exe suffix before I start to type the arguments for the command. Ideally, I’d like to avoid having to do this every time I run a command.




What I’ve tried/researched


I figured that is probably not possible without modifying the source code of the Cygwin DLL or of Bash’s command completion (pcomplete.c). However, I notice that the Bash builtins, type and command automatically strip the .exe suffix from the names of executable files, e.g.,


$ type -a openssl
openssl is /usr/bin/openssl

$ command -v openssl
/usr/bin/openssl

It seems that Bash running in Cygwin has some mechanism for providing the bare command name (without the .exe extension). However, I’ve been at a loss as to how – or if – this can be used to omit the file extension when completing commands.



Answer



It turns out that there is a configuration option in Cygwin that configures Bash to not include a filename’s .exe extension when it completes the name of a command.


Enabling the completion_strip_exe option (specific to the Cygwin port of Bash) does what I want:


shopt -s completion_strip_exe



This feature is not very obviously documented: it gets a cursory mention in the Pathname Expansion section of the Cygwin man page for Bash (it is not included in the upstream source code so is not documented in the official man page or documentation for Bash). I came across it while perusing /usr/share/doc/Cygwin/bash.README (some 4 months after asking this question):



7b. using 'shopt -s completion_strip_exe' makes completion strip .exe suffixes.



It seems that this option has been available in Cygwin Bash for over 5 years:



----- version 4.1.9-1 -- 2010-12-29 -----
Add EXECIGNORE and completion_strip_exe patches from Dan Colascione.



Further research shows that the patch for this feature was submitted by Dan Colascione back in November 2010 with the following description:



completion_strip_exe is a new shell option. When enabled, bash tries to use the short name of a program instead of its longer ".-exe"-suffixed one. With this on, pin completes to "ping".



Many thanks to Dan Colascione (I've just sent him a personal email to thank him personally) for this feature and the Bash maintainers for providing such a great shell.


Comments

Popular Posts

How do I transmit a single hexadecimal value serial data in PuTTY using an Alt code?

I am trying to sent a specific hexadecimal value across a serial COM port using PuTTY. Specifically, I want to send the hex codes 9C, B6, FC, and 8B. I have looked up the Alt codes for these and they are 156, 182, 252, and 139 respectively. However, whenever I input the Alt codes, a preceding hex value of C2 is sent before 9C, B6, and 8B so the values that are sent are C2 9C, C2 B6, and C2 8B. The value for FC is changed to C3 FC. Why are these values being placed before the hex value and why is FC being changed altogether? To me, it seems like there is a problem internally converting the Alt code to hex. Is there a way to directly input hex values without using Alt codes in PuTTY? Answer What you're seeing is just ordinary text character set conversion. As far as PuTTY is concerned, you are typing (and reading) text , not raw binary data, therefore it has to convert the text to bytes in whatever configured character set before sending it over the wire. In other words, when y...

linux - Extract/save a mail attachment using bash

Using normal bash tools (ie, built-ins or commonly-available command-line tools), is it possible, and how to extract/save attachments on emails? For example, say I have a nightly report which arrives via email but is a zip archive of several log files. I want to save all those zips into a backup directory. How would I accomplish that? Answer If you're aiming for portability, beware that there are several different versions of mail(1) and mailx(1) . There's a POSIX mailx command, but with very few requirements. And none of the implementations I have seem to parse attachments anyway. You might have the mpack package . Its munpack command saves all parts of a MIME message into separate files, then all you have to do is save the interesting parts and clean up the rest. There's also metamail . An equivalent of munpack is metamail -wy .

ubuntu - Why does my USB hdd returns SG_IO: bad/missing sense data?

I am able to boot and run commands from external USB hdd; the message in question appears for about 45 seconds then booting continues. GRUB2 is installed on internal HDD. When choosing to boot directly to /dev/sdb the message doesn't appear, however boot time is about the same as booting to internal HDD. /dev/sdb: Timing cached reads: 1018 MB in 2.00 seconds = 508.97 MB/sec Timing buffered disk reads: 80 MB in 3.03 seconds = 26.37 MB/sec pfeiffep@de:~$ sudo hdparm -i /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 10 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 HDIO_GET_IDENTITY failed: Invalid argument Gparted correctly identifies the drive as SAMSUNG MP0402H. Any ideas how to remedy the HDIO & SG_IO messages?

Desktop reboots itself on sleep or hibernate

I have been using an ASUS M2NPV-VM motherboard for main home desktop workstation, operating Windows Vista x64. This computer has right from day one not been able to enter hibernate or standby; after Windows performs its final actions and brings the machine down, it would automatically revive itself for a reboot. Updating to the second latest BIOS (1201)has not helped (the latest BIOS revision would induce video refresh problems rendering it unusable). I have been reading related discussions on incidents similar to mine to no avail of a true workable solution. They appear to be more speculative guesses rather than actual knowledge on the inner workings of motherboard hardware. Does anybody have any electronic engineering experience on PC energy-saving standards to provide a more informed opinion how to go about getting this to work? More stories: this motherboard could not even reboot properly the first thing i used it. It was due to refresh rate of the onboard GPU, which had no influe...