-e and permission denied

[victor]

-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/onlinepubs/9699919799/utilities/test.html

Re: -e and permission denied

[victor]

пятница, 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://www.gnu.org/software/bash/manual/bash.html ).

It's not immediately clear that false is returned if file exists but permission 
denied error happens.

Re: -e and permission denied

[victor]

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

[victor]

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)
> 
> > ?
> And how do you propose to back up a file that you do not have permission
> 
> to access?  For all intents and purposes, the file may as well not exist
> 
> in the first place.
> 
I described use-case when user needs to *throw an error* when backup is 
impossible.

That's important to know that backup failed in this use-case.

Re: -e and permission denied

[victor]

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 access:
- if file exists - backup, if file does not exist - all ok.

if you don't have access:
- you are not sure if file exists or no, throw error just in case (to ask user 
to fix permission or file list)

Command like "find" warns about permission denied errors, so, probably "find" 
programmers found a case when not exists vs unaccessible is matters.

Also, sometimes -e reports that file exists even if it's unreadable (example 
below), so one might have expiration that his script properly
cathes IO errors.



==
#!/bin/bash

# cleanup
chmod -R 777 X
rm -rf X
#/cleanup

mkdir X
mkdir X/Y
touch X/Y/file
touch X/f

chmod 000 X/Y
chmod 000 X/f

cat X/Y/file || echo FAIL1
cat X/Y/notafile || echo FAIL2
cat X/f || echo FAIL3

if [ -e X/f ]; then
echo X/f exists
fi

if [ -e X/Y/file ]; then
echo X/Y/file exists
fi

if [ -e X/Y/notafile ]; then
echo X/Y/notafile exists
fi

find X
==

==
cat: X/Y/file: Permission denied
FAIL1
cat: X/Y/notafile: Permission denied
FAIL2
cat: X/f: Permission denied
FAIL3
X/f exists
X
X/f
X/Y
find: `X/Y': Permission denied
==

Re: -e and permission denied

[victor]

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

[victor]

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

[victor]

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.

Some incorrect behaviour for BASH arrays

[Victor Pasko]

Hi,

On my Win-7 64-bit using Cygwin


*% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


*% echo LANG=$LANG; echo LC_ALL=$LC_ALL*LANG=
LC_ALL=

Attached please find bug.bash to reproduce incorrect BASH behaviour for
BASH arrays
and look at ways to run it


*% . bug.bash no*
VERBOSE=no
GOOD variants of sed
string=Bb12345678 QSTRING=10
result=Bb12345678 size=10 Bb12345678

string=bB123-4567-8 QSTRING=12
result=bB123\-4567\-8 size=14 bB123\-4567\-8
BAD variants of sed
string=Bb12345678 QSTRING=10
result=B size=1 B

string=bB123-4567-8 QSTRING=12
result=b size=1 b
GOOD variant of rev
string=123456789 QSTRING=9
result=987654321 size=9
BAD variant of rev
string=123456789 QSTRING=9
result=9 size=1


*% . bug.bash yes*
VERBOSE=yes
GOOD variants of sed
string=Bb12345678 QSTRING=10
DEBUG i-symbol=B
DEBUG i-symbol=b
DEBUG i-symbol=1
DEBUG i-symbol=2
DEBUG i-symbol=3
DEBUG i-symbol=4
DEBUG i-symbol=5
DEBUG i-symbol=6
DEBUG i-symbol=7
DEBUG i-symbol=8
result=Bb12345678 size=10 Bb12345678

string=bB123-4567-8 QSTRING=12
DEBUG i-symbol=b
DEBUG i-symbol=B
DEBUG i-symbol=1
DEBUG i-symbol=2
DEBUG i-symbol=3
DEBUG i-symbol=-
DEBUG i-symbol=4
DEBUG i-symbol=5
DEBUG i-symbol=6
DEBUG i-symbol=7
DEBUG i-symbol=-
DEBUG i-symbol=8
result=bB123\-4567\-8 size=14 bB123\-4567\-8
BAD variants of sed
string=Bb12345678 QSTRING=10
DEBUG i-symbol=B
DEBUG i-symbol=b
DEBUG i-symbol=1
DEBUG i-symbol=2
DEBUG i-symbol=3
DEBUG i-symbol=4
DEBUG i-symbol=5
DEBUG i-symbol=6
DEBUG i-symbol=7
DEBUG i-symbol=8
result=B size=1 B

string=bB123-4567-8 QSTRING=12
DEBUG i-symbol=b
DEBUG i-symbol=B
DEBUG i-symbol=1
DEBUG i-symbol=2
DEBUG i-symbol=3
DEBUG i-symbol=-
DEBUG i-symbol=4
DEBUG i-symbol=5
DEBUG i-symbol=6
DEBUG i-symbol=7
DEBUG i-symbol=-
DEBUG i-symbol=8
result=b size=1 b
GOOD variant of rev
string=123456789 QSTRING=9
DEBUG i-symbol=9
DEBUG i-symbol=8
DEBUG i-symbol=7
DEBUG i-symbol=6
DEBUG i-symbol=5
DEBUG i-symbol=4
DEBUG i-symbol=3
DEBUG i-symbol=2
DEBUG i-symbol=1
result=987654321 size=9
BAD variant of rev
string=123456789 QSTRING=9
DEBUG i-symbol=9
DEBUG i-symbol=8
DEBUG i-symbol=7
DEBUG i-symbol=6
DEBUG i-symbol=5
DEBUG i-symbol=4
DEBUG i-symbol=3
DEBUG i-symbol=2
DEBUG i-symbol=1
XXX-break i=9 result=9 size=1
result=9 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.bash
Description: Binary data

Re: Some incorrect behaviour for BASH arrays

[Victor Pasko]

Thanks for prompt response. But see my comments below.

Well, instead of the following line

RESULT=''

done

declare -p RESULT

without initialization, because otherwise I got the following error "-bash:
declare: RESULT=: not found".

And after deleting/commenting the following fragment in badrev

#if [ $i -ge $QSTRING ] ; then
#echo "XXX-break i=$i result=$RESULT size=${#RESULT}"
#break
#fi

and correcting end echo-line to

echo " result=${RESULT[0]} size=${#RESULT[0]}"

i can see strange output for badrev:
declare -a RESULT=([0]="987654321" [1]="B" [2]="1" [3]="2" [4]="3" [5]="\\"
[6]="-" [7]="4" [8]="5" [9]="6" [10]="7" [11]="\\" [12]="-" [13]="8")
result=9 size=1
Still incorrect output and size:( How to get correct output? ${RESULT[0]}
???

result=${RESULT[0]} size=${#RESULT[0]} ### does not work :(

BTW, in the presented link to the manual with  *6.7 Arrays*
there is no explanation for *declare -p *:(

Still unclear output for badsed

BAD variants of sed
string=Bb12345678 QSTRING=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")
DEBUG i-symbol=B
DEBUG i-symbol=b
DEBUG i-symbol=1
DEBUG i-symbol=2
DEBUG i-symbol=3
DEBUG i-symbol=4
DEBUG i-symbol=5
DEBUG i-symbol=6
DEBUG i-symbol=7
DEBUG i-symbol=8
result=B size=1


On Thu, Aug 31, 2023 at 4:49 AM Lawrence Velázquez  wrote:

> On Wed, Aug 30, 2023, at 2:12 PM, Victor Pasko wrote:
> > Attached please find bug.bash to reproduce incorrect BASH behaviour for
> > BASH arrays
> > and look at ways to run it
>
> Your tests are flawed.  The lines you use to inspect RESULT...
>
> > badsed() { # just array indexes are used for RESULT
> >   ...
> >   echo -n "   result=$RESULT size=${#RESULT}"
> >   echo " ${RESULT:0:$k}"
> > }
> >
> > ...
> >
> > badrev() {
> > ...
> > if [ $i -ge $QSTRING ] ; then
> > echo "XXX-break i=$i result=$RESULT size=${#RESULT}"
> > break # XXX
> > fi
> >   done
> >   echo "  result=$RESULT size=${#RESULT}"
> > }
>
> ...are actually only inspecting element 0 of RESULT.  As per the
> manual, "[r]eferencing an array variable without a subscript is
> equivalent to referencing with a subscript of 0" [*].
>
> Try using ''declare -p RESULT'' instead.
>
> [*] https://www.gnu.org/software/bash/manual/html_node/Arrays.html
>
> --
> vq
>


-- 

-- PSK

Fwd: Some incorrect behaviour for BASH arrays

[Victor Pasko]

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 *.

As to the idea behind of my request:
1) I need local variable RESULT as empty string (not array)
2) this RESULT should collect symbols taken from other strings using
${STRING:i:1} for one symbol or ${STRING:i:k} for k-symbols
So, the main question is: how to save such sub-strings in RESULT at needed
j-place?
With another words - I need RESULT as C-char-array to use it something like
this

RESULT[j]="${STRING:i:1}"

In good examples of my bug.bash file there was used kind of accumulation
data in RESULT

RESULT="$RESULT${STRING:i:1}"

What about saving data in the direct place of the RESULT-string?
After your explanations, bash-arrays are not for such actions (my words -
do not work) :(
And a way to accumulate data in RESULT is the only possible in BASH.
What is your opinion or more suggestions?
Thanks

-- PSK

Re: Fwd: Some incorrect behaviour for BASH arrays

[Victor Pasko]

Kerin ,

Thanks for this suggestion but mostly the number of parts for some string
would be equal to the size of the input string.
So, it means that for every string it needs to associate special bash-array
with the same size and in order to get the result do join all
bash-array-elements.

On Fri, 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 
> > 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 *.
> >
> > As to the idea behind of my request:
> > 1) I need local variable RESULT as empty string (not array)
> > 2) this RESULT should collect symbols taken from other strings using
> > ${STRING:i:1} for one symbol or ${STRING:i:k} for k-symbols
> > So, the main question is: how to save such sub-strings in RESULT at
> needed
> > j-place?
> > With another words - I need RESULT as C-char-array to use it something
> like
> > this
> >
> > RESULT[j]="${STRING:i:1}"
>
> You would have to reassemble RESULT from the appropriate substrings.
>
> $ RESULT=cat; STRING=moo; i=1 j=1;
> RESULT=${RESULT:0:j}${STRING:i:1}${RESULT:j+1}; declare -p RESULT
> declare -- RESULT="cot"
>
> Alternatively, use an array then finish by joining its elements, using the
> [*] subscript.
>
> f() {
> local RESULT=(c a t)
> local STRING=moo
> local IFS=
> local i=1 j=1
> RESULT[j]=${STRING:i:1}
> printf '%s\n' "${RESULT[*]}" # joins elements by first char of IFS
> (empty string)
> }
>
> --
> Kerin Millar
>


-- 

-- PSK

Re: math operations with base#prefix

[Victor Pasko]

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 argument but others with errors :(
*% ./bug.bash*

res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 1*
TESTCASE=1
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
./bug.bash: line 29: let: res = base10#010 + base10#03 * 3: syntax error:
invalid arithmetic operator (error token is "#010 + base10#03 * 3")
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 2*
TESTCASE=2
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
./bug.bash: line 35: let: res = 10#res1: value too great for base (error
token is "10#res1")
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 3*
TESTCASE=3
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
./bug.bash: line 44: 10#res1: value too great for base (error token is
"10#res1")
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 4*
TESTCASE=4
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
./bug.bash: line 49: let: res = base10#010: syntax error: invalid
arithmetic operator (error token is "#010")
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 5*
TESTCASE=5
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
./bug.bash: line 52: let: res = base10#res1: syntax error: invalid
arithmetic operator (error token is "#res1")
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 6*
TESTCASE=6
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
res1=010 good result 010 base8
./bug.bash: line 57: let: res1 = 10#res1: value too great for base (error
token is "10#res1")
base10-res1=10 good result 10
res1=16 good result 16


*% ./bug.bash 7*
TESTCASE=7
res1=010 good 010 base8
res2=03 good 03 base8
res=17 good result 17 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
base10-res=19 good result 19 base10 (res1+3*res2)
res1=8 good result 8 base10
res1=10 good result 10
res1=10 good result 10
res1=010 good result 010 base8
base10-res1=10 good result 10
res1=16 good result 16
./bug.bash: line 63: base16#010: syntax error: invalid arithmetic operator
(error token is "#010")

-- 

-- PSK


bug.bash
Description: Binary data

Re: math operations with base#prefix

[Victor Pasko]

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,
> >
> > 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
>
> All the examples use the base#number syntax, where `base' is a (decimal)
> number and `number' is an integer constant in that arithmetic base.
>
> The issues seem to be misunderstandings and unwarranted expectations.
> Several of the test cases use (literal) base10#number, which is an obvious
> error -- the base is a number and doesn't include the word `base'. Others
> seem to assume that the number, which is an integer constant, can include
> non-digits that are out of range for the current base.
>
> For instance, when the base is, say, 32, you can use `res1' as an integer
> constant, because those are all valid in base 32, which uses
> 0123456789abcdefghiklmnopqrstuv as `digits' (if I've counted right). In
> base 10, those are invalid.
>
> There's also some confusion about word expansion. The arguments to `let'
> and the words between $(( and )) undergo the word expansions documented
> in the man page under `Arithmetic Expansion' before the expression goes
> to the arithmetic evaluator. This means that something like `$base10#$res1'
> will expand to a word with the current values of the shell variables
> `base10' and `res1' (e.g., `10#010') before the arithmetic evaluator is
> invoked.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>

-- 

-- PSK

Strange results

[Victor Pasko]

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 result
echo11
 
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

-- 

-- PSK


bug2.bash
Description: Binary data

Fwd: Strange results

[Victor Pasko]

-- 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's 10th from the end" which is
> "u". What did you expect it to output?
>
> echo "echo11 ${ASCII_SET:-10:1}"
>

Firstly, expected the only one symbol from  ASCII_SET string

This says, according to the man page:
>
>${parameter:-word}
>   Use Default Values.  If parameter is unset or null, the
> expansion of word is substituted.  Otherwise, the value of parameter is
> substituted
>
> which means output "10:1" if ASCII_SET is unset or null. Since it isn't,
> the contents of that variable are output giving you a long sequence of
> ASCII characters.
>

But ASCII_SET is not unset so -word must not be used

-- 

-- PSK


-- 

-- PSK

Re: Fwd: Strange results

[Victor Pasko]

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
> > Subject: Re: Strange results
> > To: Dennis Williamson 
> >
> >
> >
> > Also
> >
> > echo10 ${ASCII_SET:$((-10)):1}
>
> This is the "Substring Expansion" kind of parameter expansion.
> >
> > and
> >
> > echo11 ${ASCII_SET:-10:1}
>
> This is the "Use Default Values" kind of parameter expansion.
>
> >
> > have different behaviour:(
>
> Substring expansions already imply a numeric context. A single pair of
> enclosing brackets is enough to avoid this pitfall.
>
> ${ASCII_SET:(-10):1}
>
> Another method is to have a leading space.
>
> ${ASCII_SET: -10:1}
>

 Well, it's kind of a workaround to use brackets or extra space, but how to
recognize such expectations according to string operation with -10:1 ?

>
> > Both of these say "output the character that's 10th from the end" which
> is
> > > "u". What did you expect it to output?
> > >
> > > echo "echo11 ${ASCII_SET:-10:1}"
> > >
> >
> > Firstly, expected the only one symbol from  ASCII_SET string
> >
> > This says, according to the man page:
> > >
> > >${parameter:-word}
> > >   Use Default Values.  If parameter is unset or null, the
> > > expansion of word is substituted.  Otherwise, the value of parameter is
> > > substituted
> > >
> > > which means output "10:1" if ASCII_SET is unset or null. Since it
> isn't,
> > > the contents of that variable are output giving you a long sequence of
> > > ASCII characters.
> > >
> >
> > But ASCII_SET is not unset so -word must not be used
>
> It behaves precisely as the manual states. The parameter, ASCII_SET, is
> neither unset nor null (empty). Therefore, the value of the parameter is
> substituted, rather than the given word of "10:1".
>

 How to recognize such expectations according to string operation with
-10:1 ?

-- 
> Kerin Millar
>

Let me ask more questions presented in the sent bug2.bash
Look at the following lines:

*printf -v a_int '%d' "'a" *# very strange syntax here to use char as
integer
echo "echo4 $a_int"   # should be 97 at the end


echo "echo5 *${ASCII_SET:$((a_int-12)):1}" *# you can see letter u at the
end as at 97-12=85 place
echo "echo5.1 ${ASCII_SET:a_int-12:1}"# you can see letter u at the end
as at 97-12=85 place

1) Could you please suggest elegant way to cast string symbol to
integer instead of printf for  * "'a"*
2) Here are some unsuccessful examples to use bitwise operations with
symbols:

% echo $(("'a" >> 4))
-bash: 'a >> 4: syntax error: operand expected (error token is "'a >> 4")


% echo $(("a" >> 4))
0


% echo -n $(("a" >> 4)) | xxd -p
30


% echo -n $(("a" >> 2)) | xxd -p
30


-- 

-- PSK

Why are parameters to Bash's builtin optional?

[Victor Engmark]

(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-op an error? Is there a use case for this? A more useful result 
would be an error code or, even better, listing the currently available 
builtins.

Cheers,
V

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

[Victor Engmark]

Re-post from 
<http://unix.stackexchange.com/questions/36752/why-are-parameters-to-bashs-command-and-type-optional>:

[T]hese commands print nothing and return exit code 0 if no parameters are 
provided. But [...] `help command` and `help type` both state that at least one 
parameter is mandatory. Is this a bug, a feature, or did I misunderstand 
something?

$ bash --version
GNU bash, version 4.2.10(1)-release (x86_64-pc-linux-gnu)
$ type -a command
command is a shell builtin
$ type -a type
type is a shell builtin
$ help -s command
command: command [-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?

[Victor Engmark]

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 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-op an error? Is there a use case for this? A more useful 
> > result would be an error code or, even better, listing the currently 
> > available builtins.
> 
> What's the use case for having it be an error?

Since it's a nonsensical command, and since developers who haven't learned 
proper quoting shouldn't be shot too hard in the foot when they run `builtin 
$empty`. Or maybe they should be - Quoting is such a different matter from 
mainstream languages (and *much* more complex) that maybe `builtin` should 
print simply "Use More Quotes!" Seriously though, Bash is difficult enough as 
it is, and a spoonful of language fussiness is worth a ton of guard code.

>  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 
*never* modifies their state.

Cheers,
V

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

[Victor Engmark]

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 
>> *never* modifies their state.
>
> What difference does that make?  enable -a prints all builtins, and does
> not modify their state unless told to do so.

Isn't that rather weird semantics? I'd expect `enable -a` to enable
all builtins and print nothing, and `enable -l` to list all builtins,
like the semantics of most *nix tools.

Also, I suppose `builtin`, if it printed builtins, would print *just*
the names of the builtins (unlike enable), so you wouldn't have to
parse the output even a little bit.

> Why not try out something like the following and see what you
> think:
>
> builtin()
> {
>        case $# in
>        0)      enable -a ; return 0 ;;
>        *)      command builtin "$@" ;;
>        esac
> }
>
> That might be enough to make it work for you.

Oh, this wasn't about any non-working script code, but rather to point
out that the behavior of `builtin` is not as expected, and `help
builtin` doesn't mention what it does when no parameters are provided.
I simply propose that the `shell-builtin` argument should be
mandatory, to avoid confusion.

Cheers,
V

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

[Victor Engmark]

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-to-bashs-command-and-type-optional>
>> >:
>>
>> [T]hese commands print nothing and return exit code 0 if no parameters
>> are provided. But [...] `help command` and `help type` both state that at
>> least one parameter is mandatory. Is this a bug, a feature, or did I
>> misunderstand something?
>>
>
> command executes the named argument as a command.
>
> It is perfectly valid to type in nothing at the command line and expect
> no error.
>

Actually, if you type in a command, and then press Enter more than once,
the exit code is *kept*, as if you had pressed Enter only once. So pressing
Enter on an empty command line is *not* the same as saying `:`, or `true`.

A similar argument like can be proposed for type.
>
> You give it nothing as input, why would you expect output?
>

The issue is rather that the synopsis is *inconsistent* with the
functioning of `type` and `command`. For example, the `watch` command
requires a command string as its last parameter, and without it, it prints
its own synopsis and returns with exit code 1, as expected.

My suggestion is simply that unless someone can show that somehow the
synopsis *is* consistent with the functioning of these builtins, the
synopsis should be corrected *or* the functioning of these commands should
be changed, in order to be consistent with most other *nix tools.

Cheers,
V

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

[Victor Yarema]

Hello.

In the latest version of online manual for gnu bash,
in chapter "4.3.1 The Set Builtin"
(https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
there is obscure explanation to option "-a".
The sentence says "Mark variables and function which are modified or
created for export to ...".
First time when I read it I thought that the words "are modified or
created for export" should be treated as one statement.
But later, after I read descriptions from other sources I have found
that "for export" is related to the word "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

[Victor Porton]

On Mon, 2016-01-04 at 14:59 -0500, Chet Ramey wrote:
> On 1/4/16 1:30 PM, por...@narod.ru wrote:
> 
> > Bash Version: 4.3
> > Patch Level: 42
> > Release Status: release
> > 
> > Description:
> > 
> > There should be an easy way to remove the currently 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

[Victor Porton]

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 Version: 4.3 Patch Level: 42 Release Status: release
> > > > Description:
> > > > There should be an easy way to remove the currently 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.
> 
> I did; is that significantly easier, and enough in demand, to make
> the
> implementation effort worthwhile?
It is important for security:
It should be easy to remove lines with passwords and potentially
harmful commands (like sudo with rm).


-- 
Victor Porton - http://portonvictor.org

Re: Feature: Easily remove current command from history

[Victor Porton]

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 be easy to remove lines with passwords and potentially
> > > harmful
> > > commands (like sudo with rm).
> > 
> > never put your passwords in plain text in commands, thats important
> > for security. If, for some reasons, you have to type sensitive data
> > inline, take any precautions available to not to put the command in
> > the history.
> 
> Such measures may include prefixing the command with a space when you
> enter it, if you have ignorespace or ignoreboth in the HISTCONTROL
> variable.
I know. But I sometimes forget to put a space. Also some server
accounts may be not configured for ignorespace.

-- 
Victor Porton - http://portonvictor.org

mtab and /proc/meminfo

[Victor Hugo Erminpour]

Hello all,

I'm running strace against 2.05b.0(1)-release and I can
see that bash is opening /etc/mtab and /proc/meminfo,
but I can't find any reference to this in the code.
Also, this appears when I run bash as "/bin/sh -c ".

Here's the strace output:

{{{
...
open("/etc/mtab", O_RDONLY) = 3 
fstat64(3, {st_mode=S_IFREG|0644, st_size=22472, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb73e2000
read(3, "/dev/cciss/c0d0p2 / ext3 rw 0 0\n"..., 4096) = 4096
close(3)= 0 
munmap(0xb73e2000, 4096)= 0 
open("/proc/meminfo", O_RDONLY) = 3 
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb73e2000
read(3, "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