feature request: file_not_found_handle()
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. i found this old (Dec, 2009) discussion : http://gnu-bash.2382.n7.nabble.com/command-not-found-handle-not-called-if-command-includes-a-slash-tp7118.html Why are the patches not part of the bash? Use case: -see: command_not_found_handle() Cheers, Andreas
Re: feature request: file_not_found_handle()
On Wed, Aug 14, 2013 at 01:44:08PM +0200, 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.
>
> i found this old (Dec, 2009) discussion :
> http://gnu-bash.2382.n7.nabble.com/command-not-found-handle-not-called-if-command-includes-a-slash-tp7118.html
>
> Why are the patches not part of the bash?
>
> Use case:
> -see: command_not_found_handle()
It didn't occur to me to see if there was a file_not_found_handle() hook,
but I'd use it if available. I use the command_not_found_handle() all the
time in my 'thinobject' object-oriented shell system, but need to avoid
slashes to invoke the hook per the subject 'bug' (still not sure it's really
a bug).
$ declare -f command_not_found_handle
command_not_found_handle ()
{
exec /opt/bin/tob "$@"
}
The tob program looks for a special file to infer the type of an object,
and works if either / or . delimits objects, e.g.,
$ tob rooftop.ingest.types
Telemetry-CR1000-Site:Directory:Object
$ tob rooftop/ingest.types
Telemetry-CR1000-Site:Directory:Object
But the handler is not invoked in the latter case.
$ rooftop.ingest.types
Telemetry-CR1000-Site:Directory:Object
$ rooftop/ingest.types
-su: rooftop/ingest.types: No such file or directory
It'd be great to have this fixed, or to have a file_not_found_handle().
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()
in this case, or whether it might be confusing as to when it gets invoked.
Ken
Inaccurate modification date testing
According to the manual of bash file1 -nt file2 True if file1 is newer (according to modification date) than file2, or if file1 exists and file2 does not Bash is innacurate when testing modification dates. It ignores fractions of a second. Is it expected? Coreutils test does it properly. [kruger@localhost sdl]$ touch a; touch b [kruger@localhost sdl]$ stat a b File: 'a' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd02h/64770dInode: 1577914 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ kruger) Gid: ( 1000/ kruger) Context: unconfined_u:object_r:user_home_t:s0 Access: 2013-08-14 22:28:54.100234174 +0200 Modify: 2013-08-14 22:28:54.100234174 +0200 Change: 2013-08-14 22:28:54.100234174 +0200 Birth: - File: 'b' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd02h/64770dInode: 1577915 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ kruger) Gid: ( 1000/ kruger) Context: unconfined_u:object_r:user_home_t:s0 Access: 2013-08-14 22:28:54.101234176 +0200 Modify: 2013-08-14 22:28:54.101234176 +0200 Change: 2013-08-14 22:28:54.101234176 +0200 Birth: - [kruger@localhost sdl]$ test b -nt a && echo newer || echo not not [kruger@localhost sdl]$ /usr/bin/test b -nt a && echo newer || echo not newer [kruger@localhost sdl]$ cat /etc/redhat-release Fedora release 19 (Schrödinger’s Cat) [kruger@localhost sdl]$ rpm -q bash coreutils bash-4.2.45-1.fc19.x86_64 coreutils-8.21-11.fc19.x86_64
Re: Inaccurate modification date testing
2013/8/14 Jacek Krüger > Bash is innacurate when testing modification dates. It ignores fractions > of a second. Is it expected? Coreutils test does it properly. > Looks like that is fixed in 4.3-alpha http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?h=devel#n554 -- Geir Hauge
Re: Inaccurate modification date testing
On 8/14/13 4:41 PM, Jacek Krüger wrote: > According to the manual of bash > file1 -nt file2 > True if file1 is newer (according to modification date) than file2, or if > file1 exists and file2 does not > > Bash is innacurate when testing modification dates. It ignores fractions of > a second. Is it expected? Coreutils test does it properly. Bash-4.3 will use struct timespec and nanosecond granularity if it's available and in struct stat. Bash-4.2 used the traditional time_t members. 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/
