Re: Defaults when cross-compiling

2023-11-08 Thread Michael T. Kloos
It seems to me that Autoconf (configure) is making some bad choices if 
it is just guessing that support exists like that, especially when it 
has a guaranteed fallback.  It's job is to setup the build for the 
target host system.  I was able to fix the build by using 
--without-bash-malloc.  Simply unsetting HAVE_SBRK didn't work by 
itself.  It is my opinion that the behavior should be that if configure 
can't check that support exists, it should change the default build 
options to be --without-bash-malloc.  If the user, then, re-enables it 
on the configure command line with --with-bash-malloc, that is on them.


On 11/7/2023 11:11 AM, Chet Ramey wrote:

On 11/7/23 10:03 AM, Oğuz wrote:
On Tuesday, November 7, 2023, Chet Ramey > wrote:


    It's interesting that musl supports brk but not sbrk


It doesn't support locales either. I always assumed it's someone's 
toy project but looks like there are Linux distros shipping it 
instead of glibc. Huh


They probably want some minimal system for containers. dash doesn't 
handle
multibyte characters or different locales either, but distros still 
use it.






Defaults when cross-compiling

2023-11-06 Thread Michael T. Kloos
I was trying to cross-compile bash for musl libc.  The configure script reports:

checking for working sbrk... configure: WARNING: cannot check working sbrk if 
cross-compiling
yes

However, I don't believe musl libc supports sbrk.  However, autoconf seems to 
default
to assuming yes and sets the HAVE_SBRK definition.  Bash then crashes on 
xmalloc failure.  
Is this intended behavior?  




bash 5.0 on AIX 7.2 server -- Division by 0 when using bash from shell window

2020-06-30 Thread Krongard, William T. (BLM)
Greg,

Thank you, found the issue in "root" .profile, you were correct a '1' had been 
added to Prompt Command variable.


Respectfully,

William Krongard
Express Scripts Services, 
Server Support
Work:  (952)-837-7537
Cell:  (763) 442-0640
Server Support Confluence page:
Server Support landing page
To reach out to the Server Support Team through Mattermost:
https://mattermost.express-scripts.com/express-scripts/channels/server-support





-Original Message-
From: Greg Wooledge  
Sent: Monday, June 29, 2020 4:32 PM
To: Krongard, William T. (BLM) 
Cc: bug-bash@gnu.org
Subject: [EXTERNAL] Re: bash 5.0 on AIX 7.2 server -- Division by 0 when using 
bash from shell window

On Mon, Jun 29, 2020 at 08:24:01PM +, Krongard, William T. (BLM) wrote:
> Description:
> execution of "bash" from shell window gets a division by zero 
> message # bash
> bash: (1-0/roothome1): division by 0 (error token is "roothome1)")
> bash: (1-0/roothome1): division by 0 (error token is "roothome1)")
> 
> every command executed is followed by the division by 0 message

This will be caused by something in your environment -- either the PS1 
variable, or the PROMPT_COMMAND variable, or a DEBUG trap, which is being set 
in one of root's dot files on your system.

Most probably, you've got $(( )) where you meant to have $( ), or something 
along those lines.  It'll probably be obvious once you print out the contents 
of the PS1 and PROMPT_COMMAND variables, and the output of "trap" with no 
arguments.



bash 5.0 on AIX 7.2 server -- Division by 0 when using bash from shell window

2020-06-29 Thread Krongard, William T. (BLM)
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix6.1.9.0
Compiler: /opt/freeware/bin/gcc  -maix64 -O2
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: AIX es2a236d 2 7 00C746B74C00
Machine Type: powerpc-ibm-aix6.1.9.0

Bash Version: 5.0
Patch Level: 0
Release Status: release

Description:
execution of "bash" from shell window gets a division by zero message
# bash
bash: (1-0/roothome1): division by 0 (error token is "roothome1)")
bash: (1-0/roothome1): division by 0 (error token is "roothome1)")

every command executed is followed by the division by 0 message


Repeat-By:
  upgrade from bash4.4 to 5.0 issue began

Respectfully,

William Krongard
Express Scripts Services,
Server Support
Work:  (952)-837-7537
Cell:  (763) 442-0640
Server Support Confluence page:
Server Support landing 
page
To reach out to the Server Support Team through Mattermost:
https://mattermost.express-scripts.com/express-scripts/channels/server-support




Re: request

2017-07-15 Thread t

[quote=Greg]
> You don't know whether it's actually a missing quote.
[/quote]

[quote=t]
There was missing quote. Usually it is correct info from error
and it can tell also what character.
I'm not a professional programmer, but I think that,
Bash only checks the number of quotes ( for bash )
 and ignore commands with regular expressions.
( maybe grep, sed , awk )
This is a very quick method to check, but it can not accurately check.
And that is the reason
 why it does not know where to look.
The rules of programming are very determined, so exist ways to debug.
I do not ask you to fix this, because build debugger it is not easy.
This is the reason why I wrote only "add suggestion".

I do not know, You can write on the blog or other website ...
And people will write all the terms.
( for sed , awk , grep and other command when single quotes can be ignored )
In future this terms can be used for debug,
first in $() , later everything outside.



[quote=Greg]
> It could be a missing } or a missing fi or a missing esac or a missing
> done, or ANY OTHER missing or incorrect syntax element. 
[/quote]

[quote=t]
Not, because for missing "fi"  is other error and also 
this is not very accurate, but it can point to a broken function.
Poor comfort, but better than nothing.
[quote]

={
On Fri, 14 Jul 2017 09:38:03 -0400
Greg Wooledge  wrote:

> On Fri, Jul 14, 2017 at 11:09:25AM +0200, t wrote:
> > #
> > [me@linuxbox me]$ ./trouble.bash
> > ./trouble.bash: line 8430: unexpected EOF while looking for matching "
> > ./trouble.bash: line 8440 systax error: unexpected end of file
> 
> Your problem is that your script is about 8300 lines longer than it
> should be.  Writing a bash script that's over ~100 lines is crazy.
> 
> Yours is over 8000 lines.
> 
> I have no words.
> 
> > echo "We suggest check $VAR"
> > echo "because this lines of file, contain an odd number of quotes "
> 
> But lines are explicitly *allowed* to contain an odd number of quotes.
> This is how multi-line string constants are created.
> 
> body="This is the body of an email.  It has
> multiple lines.  There are so many words
> that they don't all fit on one line."
> 
> When the parser encouters a syntax error, it *cannot* know where the real
> problem is; only that there *is* one, somewhere.  You as the programmer
> have to be the one to track it down and fix it.
> 
> You know that the syntax error originates somewhere *on* or *before*
> the line number where the parser hit the brick wall and stopped.  That's
> all you know.  You don't know whether it's actually a missing quote.
> It could be a missing } or a missing fi or a missing esac or a missing
> done, or ANY OTHER missing or incorrect syntax element.
> 
> That is *one* of the reasons why bash scripts should be kept small.
> 
> > 2. Please hide e-mail for google bots, or remove this e-mail after read.
> 
> Screw you.  (And yes, this is the sanitized version.)
> 


-- 
}



request

2017-07-14 Thread t


1. Missing quotes

#
[me@linuxbox me]$ ./trouble.bash
./trouble.bash: line 8430: unexpected EOF while looking for matching "
./trouble.bash: line 8440 systax error: unexpected end of file
#

We have 2017, please add suggestions for errors

For example for "
#===
VAR=$(cat file | sed 's/[^"]//g' | awk '{ print length }' | cat -n | grep 
"[13579]$" |  awk '{print $1}')

echo "We suggest check $VAR"
echo "because this lines of file, contain an odd number of quotes "
#===

2. Please hide e-mail for google bots, or remove this e-mail after read.
Thanks !:-)



Re: repeated extended pattern substitution incredibly slow w/large variables

2016-09-19 Thread xa...@t-online.de



>  maybe I do not fully follow your example, but wouldn't you instead of:
>
> time D="${C//\[+([0-9])\]=}" # rm '[]='
>
>  want:
> 
> time D="${C//\[[0-9]*\]=}"   # rm '[]='

this would also find [!asd]. And there are other possibilities.

but that was not my problem / question.

>  your example copies a lot to D and thats what takes time, I guess.

... but only if _extended_ pattern matching is used, see my examples. Why is
extended pattern matching so slow as compared to simple pattern matching.
That's the question.


----
Gesendet mit Telekom Mail <https://t-online.de/email-kostenlos> - kostenlos und 
sicher für alle!



repeated extended pattern substitution incredibly slow w/large variables

2016-09-18 Thread xa...@t-online.de
% cpu
  20:1.647s 1.078s
  30:6.467s 4.014s
  40:   17.912s10.886s
  50:   38.178s22.391s

which seems to indicate that extended pattern matching causes the
problem.

Please CC answers to me as I am not subscribed to the list.





Gesendet mit Telekom Mail <https://t-online.de/email-kostenlos> - kostenlos und 
sicher für alle!



suspect nobody noticed these don't work ...

2016-06-02 Thread Charles T. Smith
Does anybody know how to use ?(pattern)?  Or @(pattern)?  Or any of them
except !(pattern)?  If you do an internet search, the man page is always
blithely quoted, but only !(pattern) is ever demostrated...
I wonder if the others even work?

  ?(pattern-list)
 Matches zero or one occurrence of the given patterns
  *(pattern-list)
 Matches zero or more occurrences of the given patterns
  +(pattern-list)
 Matches one or more occurrences of the given patterns
  @(pattern-list)
 Matches one of the given patterns
  !(pattern-list)
 Matches anything except one of the given patterns


$ ls -d ?(*clean*|vim)
ciho-clean  clean  vim

(not that I can think of an application - purely academic)


readline doesn't refresh properly anymore

2016-06-02 Thread Charles T. Smith
Hello,

I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't refresh
my command line when scrolling through my history - the last tokens are often
not shown until I move the cursor there.  Is that due to a change in bash?

TIA,
cts


Missing options in ulimit usage string

2011-08-14 Thread Jessica T McKellar

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' 
-DPACKAGE='bas$
uname output: Linux kid-charlemagne 2.6.38-10-generic #46-Ubuntu SMP Tue 
Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.2
Patch Level: 0
Release Status: release

Description:

`help ulimit` is missing the -b option in the usage string and is 
missing the -T option in both the usage string and the Options section of 
the help description. doc/FAQ in the bash 4.2 source tarball says both 
options were added in bash 4.0.


Repeat-By:

Run `help ulimit` and note that -b is listed in the Options 
section but not the usage string. Then look at doc/FAQ or the ulimit 
source and note that -T also exists but isn't documented.


Fix:

Attached is a patch to add usage documentation for -b and -T. I wasn't 
sure what to do about internationalization for the new text, so I left 
that alone for now.


Having the usage string and Options match is an improvement, but it's a 
little confusing that you get an "invalid option" message when you use an 
option that isn't available on your platform, e.g.:


$ ulimit -b
bash: ulimit: -b: invalid option
ulimit: usage: ulimit [-SHabcdefilmnpqrsTtuvx] [limit]

To minimally address this I added a note in the help documentation that 
not all options are available on all platforms, but a more precise error 
message when using an option that doesn't exist on your platform would be 
better.


Best regards,
-Jessicadiff -ru ../bash-4.2/builtins/ulimit.def ./builtins/ulimit.def
--- ../bash-4.2/builtins/ulimit.def	2010-05-30 18:26:37.0 -0400
+++ ./builtins/ulimit.def	2011-08-14 18:40:10.0 -0400
@@ -23,7 +23,7 @@
 $BUILTIN ulimit
 $FUNCTION ulimit_builtin
 $DEPENDS_ON !_MINIX
-$SHORT_DOC ulimit [-SHacdefilmnpqrstuvx] [limit]
+$SHORT_DOC ulimit [-SHabcdefilmnpqrsTtuvx] [limit]
 Modify shell resource limits.
 
 Provides control over the resources available to the shell and processes
@@ -46,11 +46,14 @@
   -q	the maximum number of bytes in POSIX message queues
   -r	the maximum real-time scheduling priority
   -s	the maximum stack size
+  -T	the maximum number of threads
   -t	the maximum amount of cpu time in seconds
   -u	the maximum number of user processes
   -v	the size of virtual memory
   -x	the maximum number of file locks
 
+Not all options are available on all platforms.
+
 If LIMIT is given, it is the new value of the specified resource; the
 special LIMIT values `soft', `hard', and `unlimited' stand for the
 current soft limit, the current hard limit, and no limit, respectively.
diff -ru ../bash-4.2/po/af.po ./po/af.po
--- ../bash-4.2/po/af.po	2011-01-28 22:09:25.0 -0500
+++ ./po/af.po	2011-08-14 18:40:10.0 -0400
@@ -,7 +,7 @@
 
 #: builtins.c:169
 #, fuzzy
-msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]"
+msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]"
 msgstr "Grootte beperk (Kb):"
 
 #: builtins.c:172
diff -ru ../bash-4.2/po/bash.pot ./po/bash.pot
--- ../bash-4.2/po/bash.pot	2011-01-28 22:09:18.0 -0500
+++ ./po/bash.pot	2011-08-14 18:40:10.0 -0400
@@ -2094,7 +2094,7 @@
 msgstr ""
 
 #: builtins.c:169
-msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]"
+msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]"
 msgstr ""
 
 #: builtins.c:172
diff -ru ../bash-4.2/po/bg.po ./po/bg.po
--- ../bash-4.2/po/bg.po	2011-01-28 22:09:26.0 -0500
+++ ./po/bg.po	2011-08-14 18:40:10.0 -0400
@@ -2232,7 +2232,7 @@
 msgstr ""
 
 #: builtins.c:169
-msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]"
+msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]"
 msgstr ""
 
 #: builtins.c:172
diff -ru ../bash-4.2/po/ca.po ./po/ca.po
--- ../bash-4.2/po/ca.po	2011-01-28 22:09:27.0 -0500
+++ ./po/ca.po	2011-08-14 18:40:10.0 -0400
@@ -2224,7 +2224,7 @@
 
 #: builtins.c:169
 #, fuzzy
-msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]"
+msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]"
 msgstr "ulimit [-SHacdfmstpnuv] [l?mit]"
 
 #: builtins.c:172
Binary files ../bash-4.2/po/cs.gmo and ./po/cs.gmo differ
diff -ru ../bash-4.2/po/cs.po ./po/cs.po
--- ../bash-4.2/po/cs.po	2011-01-28 22:09:27.0 -0500
+++ ./po/cs.po	2011-08-14 18:40:10.0 -0400
@@ -2210,8 +2210,8 @@
 msgstr "type [-afptP] název [název…]"
 
 #: builtins.c:169
-msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]"
-msgstr "ulimit [-SHacdefilmnpqrstuvx] [limit]"
+msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]"

Re: bash vs sh / ticks appearing

2007-12-29 Thread Tuc at T-B-O-H.NET
> 
> "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> writes:
> 
> > When I brought it over to Linux using bash its doing
> > some strange stuff...
> >
> > SCRIPT:
> >
> > #!/bin/sh -x
> >
> > SCRIPT=$1
> > shift
> > EMAIL=$1
> >
> > echo $SCRIPT
> > $SCRIPT 1>/tmp/mailifoutput.$$ 2>&1
> 
> If you want the shell to reinterpret meta characters like quotes as part
> of a parameter expansion, you need to use eval.
> 
> > sh/FreeBSD output:
> >
> > # ./script.sh "/usr/local/bin/otherprogram \"Param 1\" \"Param2\"" email
> > + SCRIPT=/usr/local/bin/otherprogram "Param 1" "Param2"
> > + shift
> > + EMAIL=email
> > + echo /usr/local/bin/otherprogram "Param 1" "Param2"
> > /usr/local/bin/otherprogram "Param 1" "Param2"
> > + /usr/local/bin/otherprogram "Param 1" "Param2"
> 
> The FreeBSD shell apparently displays the trace ambigously.
> 
> > bash 3.00.15(1)-release/Centos Linux 2.6.9-42.0.10.EL
> > [EMAIL PROTECTED] tmp]# ./script.sh "/usr/local/bin/otherprogram \"Param 
> > 1\" \"Param2\"" email
> > + SCRIPT='/usr/local/bin/otherprogram "Param 1" "Param2"'
> > + shift
> > + EMAIL=email
> > + echo /usr/local/bin/otherprogram '"Param' '1"' '"Param2"'
> > /usr/local/bin/otherprogram "Param 1" "Param2"
> > + /usr/local/bin/otherprogram '"Param' '1"' '"Param2"'
> 
> > Why does it insert the ticks,
> 
> They are single quotes and show you unambiguously the command that is
> being exected.  You can copy the line minus the leading + into the shell
> command line and get exactly the same command executed.
> 
> > which end up making /usr/local/bin/otherprogram fail?
> 
> If the FreeBSD shell does not execute the script the same way as Bash
> then it has a serious bug.
> 
Ok... So FreeBSD sh has a bug, I'll take that up with them. 

Looks like the eval worked, thank you. 

Tuc




bash vs sh / ticks appearing

2007-12-29 Thread Tuc at T-B-O-H.NET
Hi,

I normally run a program on FreeBSD using its sh, and 
it runs fine.

When I brought it over to Linux using bash its doing
some strange stuff...

SCRIPT:

#!/bin/sh -x

SCRIPT=$1
shift
EMAIL=$1

echo $SCRIPT
$SCRIPT 1>/tmp/mailifoutput.$$ 2>&1




sh/FreeBSD output:

# ./script.sh "/usr/local/bin/otherprogram \"Param 1\" \"Param2\"" email
+ SCRIPT=/usr/local/bin/otherprogram "Param 1" "Param2"
+ shift
+ EMAIL=email
+ echo /usr/local/bin/otherprogram "Param 1" "Param2"
/usr/local/bin/otherprogram "Param 1" "Param2"
+ /usr/local/bin/otherprogram "Param 1" "Param2"

bash 3.00.15(1)-release/Centos Linux 2.6.9-42.0.10.EL
[EMAIL PROTECTED] tmp]# ./script.sh "/usr/local/bin/otherprogram \"Param 1\" 
\"Param2\"" email
+ SCRIPT='/usr/local/bin/otherprogram "Param 1" "Param2"'
+ shift
+ EMAIL=email
+ echo /usr/local/bin/otherprogram '"Param' '1"' '"Param2"'
/usr/local/bin/otherprogram "Param 1" "Param2"
+ /usr/local/bin/otherprogram '"Param' '1"' '"Param2"'


Why does it insert the ticks, which end up making
/usr/local/bin/otherprogram fail? I checked the FAQ for
"tick" and didn't see anything.

Thanks, Tuc