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
> > 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
Re: the test shell script never returns to shell
On 10/26/23 10:10 PM, wenlin wrote: Hi Chet Thanks for your response, can you or someone provide the fix patch, thanks. It will be in the next devel branch push. -- ``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/
Re: Fwd: Strange results
On Fri, 27 Oct 2023 19:28:15 +0700
Victor Pasko wrote:
> 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 ?
That much is easy to explain.
${ASCII_SET:-
^ At this point, it looks like a "Default Value" parameter expansion
Thefore, it will be treated as one. If your intention is to use a negative
offset with a Substring Expansion then you must write your code in such a way
that it can be disambiguated by the parser. Here are some other ways of going
about it.
echo "${ASCII_SET:0-10:1}"
i=-10; echo "${ASCII_SET:i:1}"
Keep in mind that the Shell Command Language specification requires that
"Default Value" parameter expansion be implemented in the way that it is, and
that there are countless scripts that depend on the status quo. However, the
Shell Command Language also doesn't suffer from this ambiguity because it
doesn't specify any means of performing "Substring Expansion" to begin with
(it's a bash extension). Since there is no way for bash to otherwise know that
"-10:1" wasn't intended as the word in ${parameter:-word}, you'll have to
choose a preferred workaround for negative offsets and live with it, as irksome
as it may be.
As concerns your other questions, I shall respond to them in a separate message.
--
Kerin Millar
Re: Fwd: Strange results
On Fri, 27 Oct 2023 15:34:16 +0100
Kerin Millar wrote:
> Keep in mind that the Shell Command Language specification requires that
> "Default Value" parameter expansion be implemented in the way that it is, and
> that there are countless scripts that depend on the status quo. However, the
> Shell Command Language also doesn't suffer from this ambiguity because it
> doesn't specify any means of performing "Substring Expansion" to begin with
> (it's a bash extension). Since there is no way for bash to otherwise know
> that "-10:1" wasn't intended as the word in ${parameter:-word}, you'll have
> to choose a preferred workaround for negative offsets and live with it, as
> irksome as it may be.
Of course, I meant to write "10:1" there, not "-10:1".
--
Kerin Millar
Re: the test shell script never returns to shell
On 10/27/2023 20:57, Chet Ramey wrote: CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. On 10/26/23 10:10 PM, wenlin wrote: Hi Chet Thanks for your response, can you or someone provide the fix patch, thanks. It will be in the next devel branch push. OK, thanks for you effort. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ -- -- Thanks Wenlin Kang
Re: Fwd: Strange results
On Fri, 27 Oct 2023 19:28:15 +0700
Victor Pasko wrote:
> 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
All implementations of the standard printf utility are required to support
this, as expressed by the third-from-last paragraph of its EXTENDED
DESCRIPTION, and the bullet points that follow it.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
>
>
> 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"*
Your request implies that printf is ill-suited to the task but I do not see
why. It allows for you to convert a character to its ordinal value according to
the system's character type (LC_CTYPE). What is your objection to using it? If
it simply that you don't consider it to be elegant, there are many other
languages to choose from.
> 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")
You are in an arithmetic context there, and must abide by its rules of syntax
(which are mostly those of ANSI C, not the printf utility). Obtain the integer
value first.
$ char=a; printf -v ord %d "'${char}"; echo $(( ord >> 4 ))
6
--
Kerin Millar
Re: Regex: A case where the longest match isn't being found
On 10/27/23 1:04 AM, Lawrence Velázquez wrote:
On Fri, Oct 27, 2023, at 12:25 AM, Grisha Levit wrote:
On Thu, Oct 26, 2023, 20:30 Dale R. Worley wrote:
I suspect the difference between the versions is how the regexp is
unquoted while it is being read, with version 3 interpreting [^\'] as
"character class excluding newline, backslash, and quote" and version 5
interpreting it as "character class excluding newline and quote".
That seems right
How? If it were right, wouldn't these produce different results?
It's not. bash-current and bash-3.2 pass the same string ("\") and
pattern ("[^']") to sh_regmatch.
--
``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/
Re: anomalies during "make test"
On 10/26/23 10:50 PM, mar...@kurahaupo.gen.nz wrote: uname output: Linux treehug.home.kurahaupo.gen.nz 5.15.0-73-generic #80-Ubuntu SMP Mon May 15 15:18:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu I don't have this exact copy of Ubuntu handy, but I just ran the bash-5.2 test suite on $ uname -a Linux ip-172-29-1-186 5.15.0-1026-aws #30-Ubuntu SMP Wed Nov 23 14:15:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux The following tests produce unexpected output during "make test". These definitely appear to indicate bugs: run-execscript (the bashdb directory isn't created during test installation, so debugger can't run) None of these tests attempt to run the debugger. In fact, the string `debug' doesn't appear in any of the scripts for this test. run-read(too few characters read) A few other people have reported this, but I've never been able to reproduce it. I changed the timeout duration for bash-5.3. run-redir (reports "bad N") The test expects file descriptor 7 to be closed, and it is in my environment. Maybe it's not in yours. Maybe I should close it explicitly in the test script. This is a bug in the test, rather than in bash: run-type(incorrectly assumes "m" does not exist in $PATH) Yes, I should use a name less likely to exist in someone's environment. These are just because I don't have the relevant locales installed: run-glob-test run-intl(and the number of tests differs) Yes, that's why the test scripts warn you about this. -- ``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/
