-e and permission denied

-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

Re: -e and permission denied

пятница, 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://

Re: -e and permission denied

пятница, 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) ?

Re: -e and permission denied

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) > >

Re: -e and permission denied

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

Re: -e and permission denied

On Friday, October 4, 2013 4:04:17 AM UTC+4, vic...@vsespb.ru wrote: > one might have expiration * inspiration

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 someth

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 c

Some incorrect behaviour for BASH arrays

size=1 *% BTW The following lines in bug.bash are just for researching and unneeded at all* if [ $i -ge $QSTRING ] ; then echo "XXX-break i=$i result=$RESULT size=${#RESULT}" break # XXX fi *% ls -al bug.bash* -rw-r--r--+ 1 victor None 2104 Aug 31 00:55 bug.bash -- -- PSK bug.

Re: Some incorrect behaviour for BASH arrays

=10 declare -a RESULT=([0]="bB123\\-4567\\-8" [1]="8" [2]="7" [3]="6" [4]="5" [5]="4" [6]="3" [7]="2" [8]="1" [9]="6" [10]="7" [11]="\\" [12]="-" [13]="8") DEBU

Fwd: Some incorrect behaviour for BASH arrays

Just forward my response to all who was involved in discussion of my request -- Forwarded message - From: Victor Pasko Date: Fri, Sep 1, 2023 at 2:23 PM Subject: Re: Some incorrect behaviour for BASH arrays To: Kerin Millar Thanks for the detailed explanations of *declare

Re: Fwd: Some incorrect behaviour for BASH arrays

, Sep 1, 2023 at 3:35 PM Kerin Millar wrote: > On Fri, 1 Sep 2023 14:44:49 +0700 > Victor Pasko wrote: > > > Just forward my response to all who was involved in discussion of my > request > > > > -- Forwarded message - > > From: Victor Pasko &

Re: math operations with base#prefix

Hi, Could you please take a look at attached bug.bash. Maybe, not all math combinations were presented there or the test has duplications somehow. Here are results of several runs with test# as argument *% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin) Good test without

Re: math operations with base#prefix

Thanks for your response. In my opinion, in let "<>" and $((<>)) constructs all variables should be evaluated, so that $-sign for them is to be just optional On Tue, Sep 19, 2023 at 2:28 AM Chet Ramey wrote: > On 9/17/23 3:59 PM, Victor Pasko wrote: > > Hi, >

Strange results

Hi, Attached please find bug2.bash. Here are results % bash --version GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin) % ./bug2.bash ASCII_SET-size=95 echo1 u echo2 u echo3 u echo4 97 echo5 u echo6 85 echo7 -10 echo8 -10 See some strange results below echo9 u echo10 u And the most strange

Fwd: Strange results

-- Forwarded message - From: Victor Pasko Date: Fri, Oct 27, 2023 at 1:57 AM Subject: Re: Strange results To: Dennis Williamson Also echo10 ${ASCII_SET:$((-10)):1} and echo11 ${ASCII_SET:-10:1} have different behaviour:( Both of these say "output the character that&#

Re: Fwd: Strange results

See my comments below inline On Fri, Oct 27, 2023 at 2:50 AM Kerin Millar wrote: > On Fri, 27 Oct 2023 02:00:01 +0700 > Victor Pasko wrote: > > > -- Forwarded message - > > From: Victor Pasko > > Date: Fri, Oct 27, 2023 at 1:57 AM > > Su

Why are parameters to Bash's builtin optional?

(Re-posted from Stack Overflow ) Running simply `builtin` prints nothing and returns exit code 0. This is in accordance with `help builtin`, which shows all parameters as optional. But why isn't this no-

Shouldn't "type" and "command" complain if there are no parameters?

[-pVv] command [arg ...] victor@victor:/home/victor/taclom/rails (master *$) $ help -s type type: type [-afptP] name [name ...] $ command $ echo $? 0 $ type $ echo $? 0

Re: Why are parameters to Bash's builtin optional?

On Wednesday, April 18, 2012 4:36:36 PM UTC+2, Chet Ramey wrote: > On 4/18/12 9:18 AM, Victor Engmark wrote: > > (Re-posted from Stack Overflow > > <http://unix.stackexchange.com/questions/36751/why-are-parameters-to-bashs-builtin-optional>) > > > > Running si

Re: Why are parameters to Bash's builtin optional?

On Fri, Apr 20, 2012 at 9:18 PM, Chet Ramey wrote: > On 4/18/12 11:27 AM, Victor Engmark wrote: >>>  I can see printing a list of builtins, though `enable' already does that. >> >> I guess the difference would be that `builtin` prints *all* builtins, and >> *ne

Re: Shouldn't "type" and "command" complain if there are no parameters?

On Thu, Apr 26, 2012 at 3:50 AM, Linda Walsh wrote: > Victor Engmark wrote: > >> Re-post from <http://unix.stackexchange.**com/questions/36752/why-are-** >> parameters-to-bashs-command-**and-type-optional<http://unix.stackexchange.com/questions/36752/why-are-parameters-t

Minor issue in bash manual. Obscure/invalid sentence in chapter "4.3.1 The Set Builtin".

ord "mark" at the beginning of sentence. I propose another description that would be more clear: For each variable or function which is modified or created mark it for export to the environment of subsequent commands. -- Victor Yarema (Віктор Ярема)

Re: Feature: Easily remove current command from history

rently selected > > command > > from the history. > > Easier than `history -d'? Look into my proposal carefully: I propose to do an equivalent of `history -d' with user pressing a single key. -- Victor Porton - http://portonvictor.org

Re: Feature: Easily remove current command from history

On Mon, 2016-01-04 at 15:14 -0500, Chet Ramey wrote: > On 1/4/16 3:09 PM, Victor Porton wrote: > > On Mon, 2016-01-04 at 14:59 -0500, Chet Ramey wrote: > > > On 1/4/16 1:30 PM, por...@narod.ru por...@narod.ru> > > > wrote: > > > > > > > Bash V

Re: Feature: Easily remove current command from history

On Mon, 2016-01-04 at 15:37 -0500, Greg Wooledge wrote: > On Mon, Jan 04, 2016 at 09:30:37PM +0100, Piotr Grzybowski wrote: > > On Mon, Jan 4, 2016 at 9:19 PM, Victor Porton > > wrote: > > > It is important for security: > > > > > > It should

mtab and /proc/meminfo

ot;total:used:free:"..., 4096) = 781 close(3)= 0 munmap(0xb73e2000, 4096) ... }}} The code seems to be in shell.c, but again no specific references to mtab or /proc/meminfo. Any ideas? Thanks, --Victor