Re: Bash 4.2 completion fails with failglob option enabled
On 2013-10-02 16:33, Andrey Osipov wrote: > Is failglob meant to be used in interactive shell? Basically, you can't use it right now if you are using completions that could return empty globs. pgpS0076Al6m7.pgp Description: PGP signature
Re: -e and permission denied
On Friday, October 4, 2013 5:10:43 AM UTC+4, Eduardo A. Bustamante López wrote:
> If you are using -e to test if a file is readable, then you're asking
>
> the wrong question. If you want to know if a file is readable, use
>
> the -r test.
>
>
>
> if [ -r some/file ]; then
>
> ... do something with file that involves reading it ..
>
> fi
>
>
>
> Regarding the 'permission denied' errors, that's an *operating
>
> system* issue. The operating system is (on purpose) not letting you
>
> know if that file exists or not, because, if you don't have the
>
> permission to check it, then you shouldn't get that information!
>
> That's the whole point of having permissions on directories, to avoid
>
> handling the list of files to users that don't have the permissions.
>
>
>
> So, at the end, if the file exists or not, you as a user cannot know,
>
> because it might, but you don't have permission to see it. So, don't
>
> expect bash to circumvent O/S security mechanisms.
>
>
>
> Better yet, most sane commands return a proper exit code when there
>
> was an error. So, if you try to read the file, but the command
>
> couldn't read it, then the command should return an error exit code,
>
> and you can test things like this:
>
>
>
> if program some/file; then
>
> everything went fine
>
> else
>
> something went wrong...
>
> fi
>
>
>
> --
>
> Eduardo A. Bustamante López
> If you are using -e to test if a file is readable
no, I am not
> The operating system is (on purpose) not letting you know if that file exists
> or not
OS is not lying about file existence. It returns "permission denied" error,
which means file may or may not exist.
> Better yet, most sane commands return a proper exit code when there was an
> error
Whole issues was that -e behaviour is not properly documented ("-e True if
file exists." is simply not true),
so user won't know that he/she needs to use right command and right logic.
example of better documentation:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
"True if pathname resolves to an existing directory entry. False if pathname
cannot be resolved."
Re: -e and permission denied
On 2013-10-04 02:18, vic...@vsespb.ru wrote: > > The operating system is (on purpose) not letting you know if that file > > exists or not > > OS is not lying about file existence. It returns "permission denied" error, > which means file may or may not exist. Nobody said the OS is lying, it's merely not telling you. $ help test | grep -- -e -e FILETrue if file exists. Since we don't know, the answer is false. I don't see what's wrong with that, or how that differs from the documentation. pgpGM3cf_AuxG.pgp Description: PGP signature
read -t 0 anomaly
I tried to use "read -t 0" to check if there is any data on the STDIN or not. The man page said: If timeout is 0, read returns success if input is available on the specified file descriptor, failure otherwise. Maybe I made a mistake but I tested and I got variable results: arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; echo $?; done | sort | uniq -c 10 0 arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; echo $?; done | sort | uniq -c 8 0 2 1 arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; echo $?; done | sort | uniq -c 10 0 I tried this on 2 machines with the same results: GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) GNU bash, 4.2.45(1)-release (x86_64-pc-linux-gnu) verzió Am I doing something wrong? Did I misunderstand the documentation? Or is there a race condition? Thanks, Arpad Kunszt
Re: -e and permission denied
On 10/04/2013 03:18 AM, vic...@vsespb.ru wrote: > >> The operating system is (on purpose) not letting you know if that file >> exists or not > OS is not lying about file existence. It returns "permission denied" error, > which means file may or may not exist. If you care about the difference between ENOENT and EPERM, then write your program in C or other language, not shell. There is no way for the shell to tell you what errno the OS returned. The shell is not going to change just because of your request. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: -e and permission denied
On Friday, October 4, 2013 3:41:58 PM UTC+4, Eric Blake wrote: > If you care about the difference between ENOENT and EPERM, then write > your program in C or other language, not shell. There is no way for the > shell to tell you what errno the OS returned. I was talking only about documentation change (so people might decide that they need distinct ENOENT and EPERM in their particular case) > The shell is not going to > change just because of your request. Of course, I understand. That was just proposal. If BASH maintainers still think current documentation is ok, I won't insist.
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád < arpad.kun...@syrius-software.hu> wrote: > I tried to use "read -t 0" to check if there is any data on the STDIN or > not. > > The man page said: > > If timeout is 0, read returns success if input is available on the > specified file descriptor, failure otherwise. > > Maybe I made a mistake but I tested and I got variable results: > > arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; > echo $?; done | sort | uniq -c > 10 0 > arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; > echo $?; done | sort | uniq -c > 8 0 > 2 1 > arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "a" | read -t 0 ; > echo $?; done | sort | uniq -c > 10 0 > > I tried this on 2 machines with the same results: > > GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) > GNU bash, 4.2.45(1)-release (x86_64-pc-linux-gnu) verzió > > > Am I doing something wrong? Did I misunderstand the documentation? Or is > there a race condition? > > Thanks, > > Arpad Kunszt There is a race condition, you cannot know if echo will run before read.
Re: read -t 0 anomaly
On 2013. October 4. 14:51:00 Pierre Gaston wrote:
> On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
...
>
>
> There is a race condition, you cannot know if echo will run before read.
I see, and it's logical. But this stills confuses me.
arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" | { sleep 1s; read -t
0; echo $?; } ; done | sort | uniq -c
10 0
I expected that the read will return non-zero in this case. I think it returned
with zero because the STDIN was still open. The docs said "read returns success
if input is available on the specified file descriptor, failure otherwise".
There wasn't any data on the file descriptor, it was just open.
Am I still doing something wrong? Or I just misunderstanding the meaning of
"input is available" term? I'm not a native English speaker (as you can se from
my mails clearly).
Thanks,
Arpad Kunszt
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád <
arpad.kun...@syrius-software.hu> wrote:
> On 2013. October 4. 14:51:00 Pierre Gaston wrote:
> > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
> ...
> >
> >
> > There is a race condition, you cannot know if echo will run before read.
>
> I see, and it's logical. But this stills confuses me.
>
> arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" | { sleep 1s;
> read -t 0; echo $?; } ; done | sort | uniq -c
> 10 0
>
> I expected that the read will return non-zero in this case. I think it
> returned with zero because the STDIN was still open. The docs said "read
> returns success if input is available on the specified file descriptor,
> failure otherwise". There wasn't any data on the file descriptor, it was
> just open.
>
> Am I still doing something wrong? Or I just misunderstanding the meaning
> of "input is available" term? I'm not a native English speaker (as you can
> se from my mails clearly).
>
> Thanks,
>
> Arpad Kunszt
>
>
Most probably read uses and does what the select() call does.
In my man select(2) I have:
"more precisely, to see if a read will not block; in particular, a
file descriptor is also ready on end-of-file"
and that's what your exemple does, echo opens stdin and then closes it and
read sees and end of file.
no worry about your english..
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston wrote:
>
>
>
> On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád <
> arpad.kun...@syrius-software.hu> wrote:
>
>> On 2013. October 4. 14:51:00 Pierre Gaston wrote:
>> > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
>> ...
>> >
>> >
>> > There is a race condition, you cannot know if echo will run before read.
>>
>> I see, and it's logical. But this stills confuses me.
>>
>> arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" | { sleep 1s;
>> read -t 0; echo $?; } ; done | sort | uniq -c
>> 10 0
>>
>> I expected that the read will return non-zero in this case. I think it
>> returned with zero because the STDIN was still open. The docs said "read
>> returns success if input is available on the specified file descriptor,
>> failure otherwise". There wasn't any data on the file descriptor, it was
>> just open.
>>
>> Am I still doing something wrong? Or I just misunderstanding the meaning
>> of "input is available" term? I'm not a native English speaker (as you can
>> se from my mails clearly).
>>
>> Thanks,
>>
>> Arpad Kunszt
>>
>>
> Most probably read uses and does what the select() call does.
> In my man select(2) I have:
>
> "more precisely, to see if a read will not block; in particular, a
> file descriptor is also ready on end-of-file"
>
> and that's what your exemple does, echo opens stdin and then closes it and
> read sees and end of file.
>
>
> no worry about your english..
>
>
> ah hmm.I spoke a bit too fastread should still not return 0 on end
of file
Re: read -t 0 anomaly
On Fri, Oct 4, 2013 at 3:30 PM, Pierre Gaston wrote:
>
>
>
> On Fri, Oct 4, 2013 at 3:29 PM, Pierre Gaston wrote:
>
>>
>>
>>
>> On Fri, Oct 4, 2013 at 3:08 PM, Kunszt Árpád <
>> arpad.kun...@syrius-software.hu> wrote:
>>
>>> On 2013. October 4. 14:51:00 Pierre Gaston wrote:
>>> > On Fri, Oct 4, 2013 at 2:20 PM, Kunszt Árpád
>>> ...
>>> >
>>> >
>>> > There is a race condition, you cannot know if echo will run before
>>> read.
>>>
>>> I see, and it's logical. But this stills confuses me.
>>>
>>> arpad@terminus ~ $ for(( i=0; i<10; i++ )); do echo -n "" | { sleep 1s;
>>> read -t 0; echo $?; } ; done | sort | uniq -c
>>> 10 0
>>>
>>> I expected that the read will return non-zero in this case. I think it
>>> returned with zero because the STDIN was still open. The docs said "read
>>> returns success if input is available on the specified file descriptor,
>>> failure otherwise". There wasn't any data on the file descriptor, it was
>>> just open.
>>>
>>> Am I still doing something wrong? Or I just misunderstanding the meaning
>>> of "input is available" term? I'm not a native English speaker (as you can
>>> se from my mails clearly).
>>>
>>> Thanks,
>>>
>>> Arpad Kunszt
>>>
>>>
>> Most probably read uses and does what the select() call does.
>> In my man select(2) I have:
>>
>> "more precisely, to see if a read will not block; in particular, a
>> file descriptor is also ready on end-of-file"
>>
>> and that's what your exemple does, echo opens stdin and then closes it
>> and read sees and end of file.
>>
>>
>> no worry about your english..
>>
>>
>> ah hmm.I spoke a bit too fastread should still not return 0 on
> end of file
>
In fact, it seems read -t0 is only a select and doesn't read anything
$ echo foo>file;read -t0 var
Re: Bash 4.2 completion fails with failglob option enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/4/13 3:32 AM, Chris Down wrote: > On 2013-10-02 16:33, Andrey Osipov wrote: >> Is failglob meant to be used in interactive shell? > > Basically, you can't use it right now if you are using completions that could > return empty globs. This just means that completions have failed to take empty globs into account, not that failglob is behaving in an unintended way. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJOxBQACgkQu1hp8GTqdKtESgCgkwUhIk8wY9sxjgMbebDbxOJ+ NXcAn3nXNOHAuOynKSupmvyiQp11sPc5 =/tF8 -END PGP SIGNATURE-
Re: Bash 4.2 completion fails with failglob option enabled
On 2013-10-04 09:35, Chet Ramey wrote: > On 10/4/13 3:32 AM, Chris Down wrote: > > On 2013-10-02 16:33, Andrey Osipov wrote: > >> Is failglob meant to be used in interactive shell? > > > > Basically, you can't use it right now if you are using completions that > > could > > return empty globs. > > This just means that completions have failed to take empty globs into > account, not that failglob is behaving in an unintended way. Right, but sadly most modules from bash-completion don't. pgparHyD5O4Ty.pgp Description: PGP signature
