make first different character bold when showing completions ala emacs
# dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4. shows phpmyadmin_4%3a4.4.15-1_all.deb phpmyadmin_4%3a4.5.0.2-2_all.deb # dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4. Can you please make the first different character bold, like emacs does, Possible completions are: phpmyadmin_4%3a4.4.15-1_all.deb phpmyadmin_4%3a4.5.0.2-2_all.deb (You can't see the bold in this ASCII email, but it is there.) In fact we see that if you line them up vertically in one column, it also helps a lot!
Want way to run background processes with SIGINT unignored
Hi. I've been wrestling recently[1] with a bash script which invokes a number of subprocesses in parallel and collects the output. The problem is that if you ^C the script, the subprocesses carry on running. This is because of the standards-mandated resetting of SIGINT (and QUIT) to SIG_IGN in children. Working around this in a race-free way with additional code in the script is very hard indeed. I can't see how to do it without having the parent install an INT trap handler which synchronises with all the children, or something equally baroque. The reason for SIGINT being ignored is purely historical: back in the dawn of time, there was no job control. If you interactively spawned a background process with &, you wouldn't want your attempts to ^C your foreground process to kill it. This SIGINT-ignoring also applied to noninteractive shells and of course came to be relied on. So it is too late to change the default :-/. However, it would be very easy for bash to provide an option (via `set -o' perhaps) to disable this behaviour. That is, to allow SIGINT to be delivered normally to child processes. With such an option, scripts which run on modern systems and which attempt to parallelise their work, would be able to arrange that ^C properly cleans up the whole process group, rather than leaving the background tasks running (doing needless work and perhaps causing lossage). I suggest that this option should have two possible modes: 1. Current behaviour (the default): SIGINT and SIGQUIT are set to SIG_IGN in the child shortly after fork. 2. In the child, reset SIGINT and SIGQUIT to the values found at shell startup. That is, uninstall trap handlers. This is what most ordinary scripts will want, because they don't want the trap handler running in both parent and child. It's the same as is done for all other signals, and for all signals in non-background subshells and subprocesses. If this sounds like a good idea, I'm happy to write the patch. Please tell me what these options should be called :-). I suggest: set -o nobgchildsigint # posix behaviour set -o bgchildsigint # reset to shell's inherited dispositions I suggest that these options do the same for both signals. Ie that it wouldn't be possible to specify the inheritance separately for INT and QUIT. This whole discussion, and these proposed options, are relevant only when job control is not in effect. Thanks, Ian. [1] http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01208.html http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01211.html
bad handling of error conditions in "type -P'
I've run across several problems with how type -P returns errors. 1) if a file isn't executable, type returns it anyway in ls -l /sbin/scat -r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat type -P scat /sbin/scat 2) if a file is inaccessible, type still returns it an answer for the path of an executable named 'scat1': ls -l /sbin/scat1 -- 1 root root 245663 Nov 19 2013 /sbin/scat1 type -P scat1 /sbin/scat1 3) bash "knows better" because it doesn't do this in "posix mode" 4) if it doesn't find the file it returns a status code meaning 'EPERM' rather than 'ENOENT'. (ENOENT No such file or directory (POSIX.1)) This is true in normal mode or posix mode. 5) if the file is executable for root, it is still return as an answer for 'type -P': ls -l /sbin/scat2 ---x-- 1 root root 245663 Nov 19 2013 /sbin/scat2 type -P scat2 /sbin/scat2 6) if bash is in posix mode it will find '/sbin/scat2' only if the owner is root (good), BUT for a non-root user, a return code of '1' is return whether it the file exists or not. NOTE: by 'coincidence' on linux, 1=EPERM, which would be correct for /sbin/scat2, but it also returns '1' for the "ENOENT" case. 7) if the file is NOT owned by root, type -P returns the alien-owned file (this seems like it would be a security risk -- but it is also in the kernel, so bash behaving differently, though correct, would be inconsistent with the insecure behavior of the kernel: ls -l /sbin/ucat2 ---x--x--- 1 nobody nogroup 245663 Nov 19 2013 /sbin/ucat2 type -P ucat2 #(normal user) # type -P ucat2 #(root user is unprotected) /sbin/ucat2 Proposals: 1) It seems the non-posix mode should parallel the posix mode in this case. 2) type should return 'EPERM' if it finds an executable owned by someone else that isn't allowed execution by the caller. 3) if no file with any executable bits is set it should return status 'ENOENT'. 4) Ideally root would not behave differently from the normal user case, since ownership by a non-priviledged user might indicate a security problem, HOWEVER, this should be brought to the attention of the kernel folks for an explanation why root can execute files owned by suspect users. Perhaps Bash being different in this case would be a best course, as it is doing a path seach, while in the kernel case, it should only be allowed if an absolute path was given (with no PATH search). I regard this as rather broken, as it gives useless, wrong and insecure answers depending on the case. I also think bash, having had it's behavior changed due to posix rules should be using posix standard errno names, doesn't that make sense? Cheers, L. Walsh
bad handling of error conditions in "type -P'
There are several problems with how type -P returns errors. 1) if a file isn't executable, type returns it anyway in ls -l /sbin/scat -r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat type -P scat /sbin/scat 2) if a file is inaccessible, type still returns it an answer for the path of an executable named 'scat1': ls -l /sbin/scat1 -- 1 root root 245663 Nov 19 2013 /sbin/scat1 type -P scat1 /sbin/scat1 3) bash "knows better" because it doesn't do this in "posix mode" 4) if it doesn't find the file it returns a status code meaning 'EPERM' rather than 'ENOENT'. (ENOENT No such file or directory (POSIX.1)) This is true in normal mode or posix mode. 5) if the file is executable for root, it is still return as an answer for 'type -P': ls -l /sbin/scat2 ---x-- 1 root root 245663 Nov 19 2013 /sbin/scat2 type -P scat2 /sbin/scat2 6) if bash is in posix mode it will find '/sbin/scat2' only if the owner is root (good), BUT for a non-root user, a return code of '1' is return whether it the file exists or not. NOTE: by 'coincidence' on linux, 1=EPERM, which would be correct for /sbin/scat2, but it also returns '1' for the "ENOENT" case. 7) if the file is NOT owned by root, type -P returns the alien-owned file (this seems like it would be a security risk -- but it is also in the kernel, so bash behaving differently, though correct, would be inconsistent with the insecure behavior of the kernel: ls -l /sbin/ucat2 ---x--x--- 1 nobody nogroup 245663 Nov 19 2013 /sbin/ucat2 type -P ucat2 #(normal user) # type -P ucat2 #(root user is unprotected) /sbin/ucat2 Proposals: 1) It seems the non-posix mode should parallel the posix mode in this case. 2) type should return 'EPERM' if it finds an executable owned by someone else that isn't allowed execution by the caller. 3) if no file with any executable bits is set it should return status 'ENOENT'. 4) Ideally root would not behave differently from the normal user case, since ownership by a non-priviledged user might indicate a security problem, HOWEVER, this should be brought to the attention of the kernel folks for an explanation why root can execute files owned by suspect users. Perhaps Bash being different in this case would be a best course, as it is doing a path seach, while in the kernel case, it should only be allowed if an absolute path was given (with no PATH search). I regard this as rather broken, as it gives useless, wrong and insecure answers depending on the case. I also think bash, having had it's behavior changed due to posix rules should be using posix standard errno names, doesn't that make sense? Cheers, L. Walsh
