Re: feature request: file_not_found_handle()
On Sat, Aug 17, 2013 at 01:46:16PM +0200, Andreas Gregor Frank wrote: > same reason for me: some object-oriented shell ( > http://oobash.sourceforge.net/) We're both running commands in the form 'object.method ...', and it works very naturally on the shell using the command-not-found hook. The problem comes when, e.g., the object is incrementally built up using tab completion so that it contains slashes, and the hook won't fire. > > "But given that the first entry on a command line pretty much has to be > a command, I'm not sure it makes sense to invoke file_not_found_handle()" > > I think you are right. On the other hand, there'd be no confusion if the handler was named to match the error message , so maybe no_such_file_or_directory_handler() could work. Still, it might be simpler to fix the current behavior. > But then we go in circles...: > http://gnu-bash.2382.n7.nabble.com/command-not-found-handle-not-called-if-command-includes-a-slash-tp7118.html > > @all: If there is a reason for not fixing this 'bug', i would like to hear. I suspect the reason may just be disinterest, and no one has made any noise about the issue. Object oriented shell is perhaps an arcane area, but I find it quite useful, and have several different systems running using it. My scheme relies on following search paths to resolve executables, and could likely largely be implemented by setting PATH dynamically according to $object, followed by exec $method. Most object oriented shell schemes that I've found and looked at are based on using the innards of shell programming, some using functions, some using arrays, some using variables, namespaces in variable name prefixes, etc. Using these systems often requires significant buy-in to the scheme, e.g., having to follow some discipline to make everything work. My interest is in trying to minimize the machinery needed to make it happen, and trying to keep necessary conventions that have to be followed to a minimum. That's the goal anyway. Methods are any ordinary executables, executed in the context of the object (the handler cd's to the object directory). The current machinery for my scheme is mostly one executable, the handler or executive, really just yet another command line interpreter or shell. The main convention is that symlinks named ^ are needed to identify the type of objects. The ^ link in a directory object resolves via the handler to a directory with methods, i.e., a bin or lib directory, which can also have a ^ link, and so on, effectively building up PATH. I have to avoid going on and on about this. I have a github project for it, but have not updated the documentation for quite a while, https://github.com/kirv/thinobject I'm not sure where an appropriate place to discuss the general topic would be, but at least the subject topic seems appropriate for bash-bug, whether as a bug or feature request. Ken
Re: feature request: file_not_found_handle()
On 8/14/13 7:44 AM, Andreas Gregor Frank wrote: > Hi, > > i think a file_not_found_handle() or a modified command_not_found_handle(), > that does not need an unsuccessful PATH search to be triggered, would be > useful and consistent. The original rationale for command_not_found_handle is that there was no other way to determine whether a command could be found with a PATH search. (well, no easy way). A PATH search is suppressed when the command to be executed contains a slash: the presence of a slash indicates an absolute pathname that is directly passed to exec(). Since there's no search done, you know exactly which pathname you're attempting to execute, and you can easily test whether or not it exists and is executable. Is there enough demand to make this feature addition worthwhile? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: autocomplete error doesn't look to be in bash-complete so I'm reporting it here.
On 8/16/13 5:28 AM, dethrop...@web.de wrote: > Bash Version: 4.2 > Patch Level: 25 > Release Status: release > > Description: > autocomplete error doesn't look to be in bash-complete so I'm reporting > it here. > > Repeat-By: > touch '>(pygmentize -l text -f html )' > rm >[Press tab] > > rm >\>\(pygmentize\ -l\ text\ -f\ html\ \) > ^ Note leading > I'm going to assume you did this in a directory with no other files, so tab-completing nothing results in the filename that strangely resembles process substitution. If you don't quote the `>', bash interprets it as a redirection operator, as the parser would, and performs filename completion. The tab results in the single filename. If you were to backslash-quote the `>', you'd get the filename as you intended. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Aw: Re: autocomplete error doesn't look to be in bash-complete so I'm reporting it here.
I got the file by running some code using procees substitution with set +o posix. I don't think the drectory was empty but what you say make sense and I didn't think to checkt it at the time. Thanks JOhn Gesendet: Sonntag, 18. August 2013 um 20:42 Uhr Von: "Chet Ramey" An: dethrop...@web.de Cc: bug-bash@gnu.org, b...@packages.debian.org, chet.ra...@case.edu Betreff: Re: autocomplete error doesn't look to be in bash-complete so I'm reporting it here. On 8/16/13 5:28 AM, dethrop...@web.de wrote: > Bash Version: 4.2 > Patch Level: 25 > Release Status: release > > Description: > autocomplete error doesn't look to be in bash-complete so I'm reporting it here. > > Repeat-By: > touch '>(pygmentize -l text -f html )' > rm >[Press tab] > > rm >\>\(pygmentize\ -l\ text\ -f\ html\ \) > ^ Note leading > I'm going to assume you did this in a directory with no other files, so tab-completing nothing results in the filename that strangely resembles process substitution. If you don't quote the `>', bash interprets it as a redirection operator, as the parser would, and performs filename completion. The tab results in the single filename. If you were to backslash-quote the `>', you'd get the filename as you intended. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu [1]http://cnswww.cns.cwru.edu/~chet/ References 1. http://cnswww.cns.cwru.edu/~chet/
Re: feature request: file_not_found_handle()
On Sun, Aug 18, 2013 at 02:35:49PM -0400, Chet Ramey wrote: > On 8/14/13 7:44 AM, Andreas Gregor Frank wrote: > > Hi, > > > > i think a file_not_found_handle() or a modified command_not_found_handle(), > > that does not need an unsuccessful PATH search to be triggered, would be > > useful and consistent. > > The original rationale for command_not_found_handle is that there was no > other way to determine whether a command could be found with a PATH search. > (well, no easy way). > > A PATH search is suppressed when the command to be executed contains a > slash: the presence of a slash indicates an absolute pathname that is > directly passed to exec(). Since there's no search done, you know exactly > which pathname you're attempting to execute, and you can easily test > whether or not it exists and is executable. > > Is there enough demand to make this feature addition worthwhile? I guess there are two people that would like to see it, so not exactly a groundswell of demand. As a user of bash, there's zero cost on my part for adding the feature, and real value in having it available. The alternative is, as now, not being able to use tab-completion easily to reach an object, or having to edit the slashes out of the command, so really just more typing. A simple workaround is to tab-complete to cd into an object (directory), at which point method calls are local, no slashes, and the command-not-found hook is fired. Thanks for considering it at least! Ken
child_pid of background process? (not in manpage?)
I don't find the variable for the process ID of the last started background process documented in the bash manpage... Am I just missing it, or did it get left out by accident or where did it go? ($!)
Re: feature request: file_not_found_handle()
Chet Ramey wrote: On 8/14/13 7:44 AM, Andreas Gregor Frank wrote: Hi, i think a file_not_found_handle() or a modified command_not_found_handle(), that does not need an unsuccessful PATH search to be triggered, would be useful and consistent. The original rationale for command_not_found_handle is that there was no other way to determine whether a command could be found with a PATH search. (well, no easy way). A PATH search is suppressed when the command to be executed contains a slash: the presence of a slash indicates an absolute pathname that is directly passed to exec(). Since there's no search done, you know exactly which pathname you're attempting to execute, and you can easily test whether or not it exists and is executable. --- How does "lib/font/fontname.ttf" indicate an absolute path? The standard interpretation for that would be a relative path from the CWD. Only if a path begins with "/" would a path normally be interpreted as absolute. Are you saying bash behaves differently from nearly every other application in this regard? This is only in non-POSIX mode? (as POSIX specifies that a path not starting with '/' is to to be taken as relative from the current directory (under Pathname Resolution: "If the pathname does not begin with a slash,...such pathnames are 'relative pathnames'..." -- meaning the CWD of the process is to be prepended). This reminds me of a the "dot" (source) command discussion but a bit reversed?, Where it uses the presence of any '/' to force a PATH relative search as the first action. So if '/' is in a "dot" path, that means it searches path for the file, but if it doesn't contain a "/" then it only looks in the CWD?? What if it starts with a "/"... does that override the PATH search?
i++ cause bad return code when result is 1
% uname -a Linux dph1d1ods13 2.6.32-279.2.1.el6.x86_64 #1 SMP Thu Jul 5 21:08:58 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux % bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) The ((i++)) fails only when the result is 1. When the result is 0 or 2, it does not fail. This is a problem when 'set -e'. ### i++ failes when ‘I’ becomes one. i=0 echo $? 0 % (( i++ )) % echo $? ### this should not fail 1 % (( i++ )) % echo $? 0 % (( i++ )) % echo $? 0
failed grep should cause subshell to exit
### should never see done ** ** % uname -a Linux x 2.6.32-279.2.1.el6.x86_64 #1 SMP Thu Jul 5 21:08:58 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux % bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) ( set -ex ** ** echo hello >x grep hello x ! grep hello x echo $? ### should not see "done" because set -e echo done )
Re: i++ cause bad return code when result is 1
On 2013-08-18 16:57, David Lehmann wrote: > The ((i++)) fails only when the result is 1. When the result is 0 or 2, it > does not fail. This is a problem when 'set -e'. This is normal and expected. If the value returned in an (( expression is zero, then the exit code is 1. Since you're using a postincrement, zero is returned, and then i is incremented to 1. pgp_Hxjx34lLU.pgp Description: PGP signature
Re: child_pid of background process? (not in manpage?)
On 2013-08-18 17:46, Linda Walsh wrote: > I don't find the variable for the process ID of the > last started background process documented in the bash manpage... > > Am I just missing it, or did it get left out by accident or > where did it go? First of all, it would help if you gave your version. At least in 4.2.45, it's under "Special Parameters". > Special Parameters > > [...] > > ! Expands to the process ID of the most recently executed >background (asynchronous) command. pgpbTqYn2G9hD.pgp Description: PGP signature
Re: feature request: file_not_found_handle()
On Sun, Aug 18, 2013 at 06:30:47PM -0700, Linda Walsh wrote: > > Chet Ramey wrote: > >On 8/14/13 7:44 AM, Andreas Gregor Frank wrote: > >>Hi, > >> > >>i think a file_not_found_handle() or a modified command_not_found_handle(), > >>that does not need an unsuccessful PATH search to be triggered, would be > >>useful and consistent. > > > >The original rationale for command_not_found_handle is that there was no > >other way to determine whether a command could be found with a PATH search. > >(well, no easy way). > > > >A PATH search is suppressed when the command to be executed contains a > >slash: the presence of a slash indicates an absolute pathname that is > >directly passed to exec(). Since there's no search done, you know exactly > >which pathname you're attempting to execute, and you can easily test > >whether or not it exists and is executable. > --- > > How does "lib/font/fontname.ttf" indicate an absolute path? It's not a question of absolute or relative in that sense, but just whether it looks like a path of any sort due to the slash. The context is for the first entry on a command line, and there's no point in searching PATH if the value has a slash. Absolute or relative path makes no difference. I suppose you could say that it's abolutely a path... > This reminds me of a the "dot" (source) command discussion but a bit > reversed?, Where it uses the presence of any '/' to force a PATH > relative search as the first action. > > So if '/' is in a "dot" path, that means it searches path for the file, > but if it doesn't contain a "/" then it only looks in the CWD?? > > What if it starts with a "/"... does that override the PATH search? It might sound similar but I don't think there's much relation between this case, where we are dealing with the command to be executed, and the source command and how it handles its arguments. We want the attempted command, e.g., lib/font/fontname.ttf, once it fails bash's attempts to execute it, to be passed to an alternative shell so it can have a go. In my system the handler would try to resolve lib/font/fontname as an object and ttf as a method, or maybe lib/font/fontname.ttf as the object and 'default' as the method. Ken
