Wanted: better(more specific) error msgs?

[L A Walsh]

Ran into a minor error where I was testing some
dec<->hex conversion values, and later testing the display
of a unicode char.

Problem happened when I re-used a var that had earlier had the
integer property set on the variable.

declare -i a=123
...
then later
a="▯"
-bash: ▯: syntax error: operand expected (error token is "▯")
(u+25AF)

(the character didn't have a font for it, so displayed
as a square)

I'm still not sure why it is giving a syntax error when
a="t", for example doesn't (it puts a value of '0' in 'a').

But if I try:
a="z", I get the syntax error again(**)


Ideally, I'd prefer to see something like printf
prints out when it finds a non number for a decimal field:
> printf "%d" "t"
-bash: printf: t: invalid number

So why does something with the integer attrib set work somewhat
'ok' (if '0' is what you expect)...oh...

(**) - because in coming up with test cases, I had tried
assigning that 'u+25af' (▯) to 'z', oh ...just weird.
if the target has the int flag set, and what you assign is not
an integer, then you might get '0' in 'a' and no error,
or you might get a syntax error...

Um...  This behavior is a bit confusing...
It would really be better if it could say what it
was expecting, like printf.

??

I guess it's based on whether or not what you are assigning
could be a variable name -- but that sorta dovetails into something
else I'd been thinking about: being able to use more unicode
characters in var and function names, like:

$☃="snowman"

hmmmWell, double the "want"/"need" for better error
messages, first.  Then might be nice to allow more
unicode class-"alnum" into the varname-composition class?

Re: hit this before undefined symbol: O_CLOEXEC

[Dennis Clarke]

On 5/25/19 5:55 PM, Chet Ramey wrote:

On 5/25/19 2:06 PM, Dennis Clarke wrote:


On any Solaris boxen there really isn't O_CLOEXEC so even after a neat
compile and test the install will blow up.


http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00167.html

You can use the patch there as a quick solution, or grab the version of
fdflags.c from the devel branch (which contains a somewhat more involved
patch).


That could work. However I just went ahead without the example file. No
big issue.


Dennis

Re: hit this before undefined symbol: O_CLOEXEC

[Chet Ramey]

On 5/25/19 2:06 PM, Dennis Clarke wrote:
> 
> On any Solaris boxen there really isn't O_CLOEXEC so even after a neat
> compile and test the install will blow up.

http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00167.html

You can use the patch there as a quick solution, or grab the version of
fdflags.c from the devel branch (which contains a somewhat more involved
patch).

Chet

-- 
``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: Bug? Bash manual not indexable by search engines

[Eduardo A . Bustamante López]

On Sat, May 25, 2019 at 02:56:43PM -0400, Richard Marmorstein wrote:
> There was discussion on Twitter today
> (https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
> Bash manual appears to not be indexable by search engines.
> 
> https://www.gnu.org/software/bash/manual/bashref.html
> redirects to
> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, and
> www.gnu.org/robots.txt
> has
> "Disallow: /savannah-checkouts/"
> 
> We reasoned that this probably wasn't deliberate and wanted to report it.

Hmmm, interesting. How did you get to 
?

I went to: , which is the "landing page" (?)
for Bash. That has:

> Documentation
> 
> *Documentation for Bash* is available online, as is documentation for most GNU
> software. You may also find more information about Bash by running info bash 
> or
> man bash, or by looking at /usr/doc/bash/, /usr/local/doc/bash/, or similar
> directories on your system. A brief summary is available by running bash 
> --help.

The "Documentation for Bash" text includes a link to:
, which then links to:
 (i.e. it's "bash.html", 
not "bashref.html").

Furthermore, if I search for "bash manual" in Google (i.e.
), the top three results (for me)
are:

1. 
2. 
3. 

So, it looks like the manual IS indexable?


I searched for "https://www.gnu.org/software/bash/manual/bashref.html; in Google
too, and I can see it's referenced from a couple of 

user submitted posts, but that's it.

Bug? Bash manual not indexable by search engines

[Richard Marmorstein]

There was discussion on Twitter today
(https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
Bash manual appears to not be indexable by search engines.

https://www.gnu.org/software/bash/manual/bashref.html
redirects to
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, and
www.gnu.org/robots.txt
has
"Disallow: /savannah-checkouts/"

We reasoned that this probably wasn't deliberate and wanted to report it.

hit this before undefined symbol: O_CLOEXEC

[Dennis Clarke]

On any Solaris boxen there really isn't O_CLOEXEC so even after a neat
compile and test the install will blow up.

Simple solution is to not install the example fdflags.c

.
.
.
/opt/developerstudio12.6/bin/cc -K pic -DHAVE_CONFIG_H -DSHELL -DSOLARIS 
-m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full 
-xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs 
-xdebugformat=dwarf -errtags=yes -errwarn=%none -D_LARGEFILE64_SOURCE 
-D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO -I. -I.. 
-I../../../bash-5.0-007_20190512031626 
-I../../../bash-5.0-007_20190512031626/lib 
-I../../../bash-5.0-007_20190512031626/builtins 
-I../../../bash-5.0-007_20190512031626/examples/loadables 
-I../../../bash-5.0-007_20190512031626/include 
-I/usr/local/build/bash-5.0-007_SunOS5.10_sparc64vii+.002 
-I/usr/local/build/bash-5.0-007_SunOS5.10_sparc64vii+.002/lib 
-I/usr/local/build/bash-5.0-007_SunOS5.10_sparc64vii+.002/builtins  -c 
-o fdflags.o 
../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c
"../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c", 
line 117: error: undefined symbol: O_CLOEXEC
"../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c", 
line 202: error: undefined symbol: O_CLOEXEC
"../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c", 
line 204: error: undefined symbol: O_CLOEXEC
"../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c", 
line 209: error: undefined symbol: O_CLOEXEC
cc: acomp failed for 
../../../bash-5.0-007_20190512031626/examples/loadables/fdflags.c

gmake[1]: *** [Makefile:100: fdflags.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/bash-5.0-007_SunOS5.10_sparc64vii+.002/examples/loadables'

gmake: [Makefile:824: install] Error 2 (ignored)
beta #

Yeah well. Okay.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: readline: How to unbind _all_ keys

[Henning]

On 24/05/2019 17:16, Chet Ramey wrote:


That's not in the distributed version of bash-5.0. If you're applying an
older cygwin patch, have you tried just building the distributed version?
Let's make sure that works.



Bang! It does. So sorry that I didn't have that idea myself. Especially
as I have never used the 'igncr' stuff anyway. I hope there won't
appear ther Windows related issues.

I'm going to explore things now. And I have been waiting for
{previous,next}-screen-line and several other things.

Thanks a lot.

Henning