-e will return file not exists, even if it does, when permission denied error
happen. I am wondering if this documented/correct behaviour or no.
this behaviour seems poorly documented in manual
http://www.gnu.org/software/bash/manual/bash.html
but butter documented here
http://pubs.opengroup.org
Hello, everyone.
bash 4.2 completion misfunctions with failglob option enabled.
This problem doesn't occur in bash 3.2.
Is failglob meant to be used in interactive shell?
$ bash --version
GNU bash, version 4.2.0(1)-release (i686-pc-linux-gnulibc1)
$ # failglob is unset
$ # completion fails
$ sh
Hello, everyone.
bash 4.2 completion misfunctions with failglob option enabled.
This problem doesn't occur in bash 3.2.
Is failglob meant to be used in interactive shell?
$ bash --version
GNU bash, version 4.2.0(1)-release (i686-pc-linux-gnulibc1)
$ # failglob is unset
$ # completion fails
$ sh
On Thu, Oct 03, 2013 at 03:18:16AM -0700, vic...@vsespb.ru wrote:
> -e will return file not exists, even if it does, when permission denied error
> happen. I am wondering if this documented/correct behaviour or no.
I assume you mean that bash will return 1 (failure) for [[ -e /path/to/file ]]
when
пятница, 4 октября 2013 г., 1:27:28 UTC+4 пользователь Greg Wooledge написал:
> I assume you mean that bash will return 1 (failure) for [[ -e /path/to/file ]]
yes
> How else would you expect bash to handle this?
Point was that it's probably poorly documented: "-e True if file exists." (
http://
On 10/03/2013 03:36 PM, vic...@vsespb.ru wrote:
> пятница, 4 октября 2013 г., 1:27:28 UTC+4 пользователь Greg Wooledge написал:
>> I assume you mean that bash will return 1 (failure) for [[ -e /path/to/file
>> ]]
>
> yes
>
>> How else would you expect bash to handle this?
>
> Point was that it'
пятница, 4 октября 2013 г., 2:11:51 UTC+4 пользователь Eric Blake написал:
> For all intents and purposes
What about the following intent:
-if file exists, backup file
-throw an error in case of permission problem (to avoid missing files in the
backup destination)
?
On 10/03/2013 04:19 PM, vic...@vsespb.ru wrote:
> пятница, 4 октября 2013 г., 2:11:51 UTC+4 пользователь Eric Blake написал:
>> For all intents and purposes
>
> What about the following intent:
> -if file exists, backup file
> -throw an error in case of permission problem (to avoid missing files i
On Friday, October 4, 2013 2:36:33 AM UTC+4, Eric Blake wrote:
> On 10/03/2013 04:19 PM, vic...@vsespb.ru wrote:
> > What about the following intent:
>
> > -if file exists, backup file
>
> > -throw an error in case of permission problem (to avoid missing files in
> > the backup destination)
>
>
On 10/03/2013 05:12 PM, vic...@vsespb.ru wrote:
>>
> I described use-case when user needs to *throw an error* when backup is
> impossible.
If test -e fails, backup is impossible. Throw an error in that case.
>
> That's important to know that backup failed in this use-case.
I don't see the di
On Friday, October 4, 2013 3:24:35 AM UTC+4, Eric Blake wrote:
> If you don't have access, then you cannot tell whether the file exists
> or not. So you might as well assume it does not exist, and write your
> script to error out if a user feeds you a name that you cannot access.
if you have acce
On Friday, October 4, 2013 4:04:17 AM UTC+4, vic...@vsespb.ru wrote:
> one might have expiration
* inspiration
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 *operatin
13 matches
Mail list logo
