bash 3.2 and bash 4.0 (RC1) fail to build statically
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Description: http://pastebin.com/f476b80da configured via: http://pastebin.com/m62b92718 Adding --enable-minimal doesn't fix the issue which means these versions basically can't be used as a statically-linked root shell? Ideally we'd be able to have a *fully* functional Bash statically linked though ;) Reported in #bash on 1st February 2009, bug request made by 'ferret'. We've both looked and can't find a duplicate for this one. Any hot tips on how to get this to build? Target system is an i486 box running Debian GNU/Linux but I've also got x86_64 boxes which will need a statically-linked Bash compiling :-) Thanks very much. -- astinus Repeat-By: configure compile watch it fail :)
Re: Parallelization of shell scripts for 'configure' etc.
Yeah honestly splitting most of the `configure` checks into multiple threads is definitely possible. Caching between projects is even a straightforward extension with systems like `Nix`. The "gotcha" here in both cases is that existing scripts that are living in source tarballs are not feasible to "regenerate" in the general case. You could have this ship out with future projects though if project authors updated to new versions of Autoconf. If you have a particularly slow package, you can optimize it in a few hours. Largely this means "identify which tests 100% match the standard implementation of a check" in which case you can fill in a cached value. But what I think y'all are asking about is "can I safely use a cache from one project in another project?" and the answer there is "no not really - and please don't because it will be a nightmare to debug". The nasty part about trying to naively share caches is that it will probably work fine ~90% of the time. The problem is that the 10% that misbehave are high risk for undefined behavior. My concern is the 0.5% that appear to work fine, but "whoops we didn't know project X extended a macro without changing the name - and now an ABI conflict in `gpgp` appears on the third Sunday of every October causing it skip encryption silently" or some absurd edge case. I think optimizating "freshly generated" scripts is totally doable though. On Mon, Jun 13, 2022, 5:40 PM Paul Eggert wrote: > In many Gnu projects, the 'configure' script is the biggest barrier to > building because it takes s long to run. Is there some way that we > could improve its performance without completely reengineering it, by > improving Bash so that it can parallelize 'configure' scripts? > > For ideas about this, please see PaSh-JIT: > > Kallas K, Mustafa T, Bielak J, Karnikis D, Dang THY, Greenberg M, > Vasilakis N. Practically correct, just-in-time shell script > parallelization. Proc OSDI 22. July 2022. > https://nikos.vasilak.is/p/pash:osdi:2022.pdf > > I've wanted something like this for *years* (I assigned a simpler > version to my undergraduates but of course it was too much to expect > them to implement it) and I hope some sort of parallelization like this > can get into production with Bash at some point (or some other shell if > Bash can't use this idea). > >
Re: Parallelization of shell scripts for 'configure' etc.
You can try to use the `requires` toposort routine to identify "Strongly Connected Sub-Components", which is where I imagine you'll get the best results. What you'll need to watch out for is undeclared ordering requirements that parallelism would break. The `m4sh` and `m4sugar` source code is documented in a lot of detail. The manuals exclude that type of documentation because it's internal; but you could keep yourself occupied for at least a month or two before you ran out of topics to explore. On Mon, Jun 13, 2022, 8:45 PM Dale R. Worley wrote: > Paul Eggert writes: > > In many Gnu projects, the 'configure' script is the biggest barrier to > > building because it takes s long to run. Is there some way that we > > could improve its performance without completely reengineering it, by > > improving Bash so that it can parallelize 'configure' scripts? > > It seems to me that bash provides the needed tools -- "( ... ) &" lets > you run things in parallel. Similarly, if you've got a lot of small > tasks with a complex web of dependencies, you can encode that in a > "makefile". > > It seems to me that the heavy work is rebuilding how "configure" scripts > are constructed based on which items can be run in parallel. I've never > seen any "metadocumentation" that laid out how all that worked. > > Dale > >
Re: Parallelization of shell scripts for 'configure' etc.
I've been telling folks about the config site file every time this thread comes up. Good on you for actually trying it haha. It can make a huge difference. You can short circuit a lot of checks this way. Now, the disclaimer: you still shouldn't share a cache file between projects, and if you use a `config.site` don't stash internal values. Be sure you keep an eye on your `config.site` values as your system is updated over time, and if you use containers or build in chroots keep in mind how that can effect the validity of your cache and `config.site` settings. On Fri, Jul 8, 2022, 3:05 PM Simon Josefsson via Discussion list for the autoconf build system wrote: > Tim Rühsen writes: > > > a) The maintainer/contributor/hacker setup > > This is when you re-run configure relatively often for the same > project(s). > > I do this normally and and came up with > > > https://gitlab.com/gnuwget/wget2/-/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain. > > > It may be a bit outdated, but may help one or the other here. > > Btw, I am down to 2.5s for a ./configure run from 25s originally. > > Wow, I think more developers should known about your final suggestion: > > > https://gitlab.com/gnuwget/wget2/-/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain#cccflags-dependent-usage-of-configure-caching > > That is, put this in ~/.bash_aliases: > > export CONFIG_SITE=~/src/config.site > > and this in ~/src/config.site: > > if test "$cache_file" = /dev/null; then > hash=`echo $CFLAGS $LDFLAGS $host_alias $build_alias|md5sum|cut -d' ' > -f1` > cache_file=~/src/config.cache.$CC.$hash > fi > > The top of config.log says which cache file was used, so you can remove > it when you hack on autoconf/M4 macros. > > This appears to save me tons of build time, and I'll run with this now > since it is non-obtrusive and doesn't require changes in each project... > maybe the CWD should be put into the cache_file string to avoid cache > poisining between projects, but that is minor. > > /Simon >
Re: [bash 4] 'test -v 1' is never true
Hi Martin,
On 11/27/22 17:53, Martin D Kealey wrote:
The expansion `$[var+replacement}` was part of the Bourne shell when I
used it in 1985 (before POSIX was first published),
I didn't know that; interesting. Still looks ugly/convoluted to me to
use that feature here. Might be useful if I didn't had another tool...
whereas `test A -gt
B` is rather newer,
Being POSIX, it's old enough for my taste :)
and `test -v` is only a Bash extension (and
similarly wasn't added until later).
Yeah, I started using that for consistency with other -v tests. In
fact, the first time I used it instead of $#, I wasn't sure if it would
work.
I think $# wins for me.
Thanks!
Alex
The man and info pages have retained the rather terse descriptions of
those oldest expansions, and they are buried in the sheer volume of the
current documentation.
On Sun, 27 Nov 2022 at 23:00, Alejandro Colomar <mailto:alx.manpa...@gmail.com>> wrote:
Hi Alexey,
On 11/27/22 12:41, Alexey wrote:
> On 2022-11-26 21:45, Alejandro Colomar wrote:
>> That was my gut; thanks! I'll workaround with $#.
>
> I could suggest you to use for clarity another construction:
> [[ ${1+isset} ]] || echo "not set"
>
> Here "isset" is just for readability. You could place any other
string literal
> there.
I actually find that very confusing. What feature is it using? I
couldn't find
it with `info bash | less` then `/\+`.
test $# -ge 1
has the benefit that it's just a sed(1) away from my old
test -v 1
And it only needs the following to be understood:
man test | grep -A1 ' -ge '
man sh | grep ' # '
The old version (test -v 1) required:
help test | grep ' -v '
man sh | sed -n '/^ Positional/,/^$/p'
Both are easy to find.
>
> Regards,
> Alexey.
Cheers,
Alex
--
<http://www.alejandro-colomar.es/ <http://www.alejandro-colomar.es/>>
--
<http://www.alejandro-colomar.es/>
OpenPGP_signature
Description: OpenPGP digital signature
Document that here strings don't support brace expansion.
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
The documentation for here strings says:
"The WORD undergoes tilde expansion, parameter and variable expansion,
command substitution, arithmetic expansion, and quote removal. Filename
expansion and word splitting are not performed."
It is missing brace expansion, which is not supported:
$ cat <<< a{b,c}d
a{b,c}d
b$ cat <<< {1..3}
{1..3}
Fix:
diff --git a/doc/bashref.texi b/doc/bashref.texi
index b0dc2fad..97d2e15a 100644
--- a/doc/bashref.texi
+++ b/doc/bashref.texi
@@ -3191,7 +3191,7 @@ A variant of here documents, the format is:
The @var{word} undergoes
tilde expansion, parameter and variable expansion,
command substitution, arithmetic expansion, and quote removal.
-Filename expansion and word splitting are not performed.
+Brace expansion, filename expansion, and word splitting are not performed.
The result is supplied as a single string,
with a newline appended,
to the command on its
--
Alex.
Re: Document that here strings don't support brace expansion.
Chet Ramey writes: > On 3/11/23 3:39 AM, Alex Bochannek wrote: >> Bash Version: 5.2 >> Patch Level: 15 >> Release Status: release >> Description: >> The documentation for here strings says: >> "The WORD undergoes tilde expansion, parameter and variable >> expansion, >> command substitution, arithmetic expansion, and quote removal. Filename >> expansion and word splitting are not performed." >> It is missing brace expansion, which is not supported: > > I wouldn't say it's missing, since it's not listed as one of the expansions > that here-strings undergo. The filename expansion and word splitting are > called out because people asked about them. To this point, no one has asked > about brace expansion. That's a fair point. I was maybe a bit surprised that this didn't work. It seems less surprising that it would not in a here-doc, but from a user's perspective, I can see someone expecting it for a here-string. I didn't submit this as a bug against the functionality because even though I think it would be useful, being consistent between here-docs and here-strings and with how Zsh does it is beneficial. Documentation that is more explicit about this is helpful in my opinion. I also noticed that there doesn't seem to be an easy way to expand braces with Readline, which I suspect may have to do with where in the parsing process of Bash brace expansion actually happens. This suggestion from a few years ago does the trick, but feels like it shouldn't be necessary. https://unix.stackexchange.com/questions/468135/bash-in-line-brace-expansion The documentation for M-C-e says "Expand the line as the shell does. This performs alias and history expansion as well as all of the shell word expansions (*note Shell Expansions::)." Maybe that can be tightened up a bit as well to clarify what it does not do? Thanks! -- Alex.
Re: Document that here strings don't support brace expansion.
Chet,
Thank you for the thoughtful responses. My thoughts below got a bit
long, so here is a summary:
- The here-string documentation should either spell out that brace
expansion is not performed or simple only list the expansions that
are.
- The same goes for the documentation for the shell-expand-line Readline
command.
- A Readline command to expand braces is a nice to have, but not
essential.
For the longer version, let's address the two issues separately, first
to Dale's point.
Chet Ramey writes:
> On 3/14/23 11:23 AM, Dale R. Worley wrote:
>> Interesting ... I would recommend adding brace expansion to the list
>> of
>> things-not-done because I think it's a common cognitive error to include
>> brace expansion as part of filename expansion -- it's one of those
>> things you do on the command line to generate a list of the files you
>> want.
>
> OK, let's assume that's true: that brace expansion and filename expansion
> are linked in your mind. Some glob(3) implementations do include it as a
> non-standard extension, in fact.
>
> If they're linked, why wouldn't saying filename generation isn't performed
> be enough to imply that brace expansion isn't performed either?
>
> I mean, it's not a huge deal -- two words. What I want to avoid is the
> expectation that not only does the documentation need to specify which
> expansions are performed, but the ones that are not. How about assuming
> that if it's not specified as being performed, it's not performed?
I first learned about brace expansion when using Csh 30-ish years ago.
Back then it was absolutely considered (and documented in the man page)
as part of "Filename substitution."
In Bash, the man page (and the info manual) says: "Brace expansion is a
mechanism by which arbitrary strings may be generated. This mechanism is
similar to pathname[filename] expansion, but the file names generated
need not exist." It has been like this since 1.14.7 in May 1995 (the
oldest version I have access to) and still is like this in 5.2 from
September 2022 - these man pages have Chet's name on it, so Chet is the
authority as to their intent. I think Dale has a fair point though that
people tend to think of brace expansion as "adjacent to" (i.e., often
used for) filename expansion and I would guess a construct like "mv
foo{.,bak}" is probably one of the most commonly used cases of brace
expansion. However, sequence expressions, while certainly also used to
construct filenames, feel a bit more removed from globbing.
Anyway, for the purposes of this issue (documentation of here-strings),
I would like to suggest that all expansions that do take place need to
be listed and all that do not are either enumerated or combined with a
phrase like: "No other expansion is performed on WORD." Ultimately, the
list of seven expansions is what the reader references as the
authoritative list, which is why the absence of brace expansion in the
here-string documentation is surprising.
Now on to the Readline point.
Chet Ramey writes:
> I assume that means you think there should be a bash-specific bindable
> command that performs brace expansion on the current word?
I think this would be a nice feature to have, especially in light of the
existence of complete-into-braces. It's interesting that this only
applies to existing files, so if there were an equivalent brace
expansion Readline command, combining it with complete-into-braces would
not result in an identity function. This may be an argument against
using M-} as a default binding for this hypothetical new function
because it would suggest a symmetry that is not there.
>> The documentation for M-C-e says "Expand the line as the shell does.
>> This performs alias and history expansion as well as all of the shell
>> word expansions (*note Shell Expansions::)." Maybe that can be tightened
>> up a bit as well to clarify what it does not do?
>
> Sure, it can list the word expansions it performs.
That would be helpful. The shell-expand-line command is really useful
and I don't think a lot of users understand what its limitations are.
Thank you!
--
Alex.
feature request: configurable history timestamps
Hi, I had initially been confused by the HISTTIMEFORMAT variable thinking it could be used to change what was written to the history file, rather than the output of the history command. Obviously it would have to be a separate variable, but the ability to add extra info to the history file would be very useful to me. Given the pid and pwd you can effectively track sessions, and know where you invoked a command in addition to when. As a simple change, just statically appending the bash pid such that the history file looks like: #1323582935 217 command would enable constructing a session and inferring the pwd by checking for cd/pushd/popd commands (assuming no other aliases or scripts are used to chdir). Note as a hack I've tried using a trap DEBUG to call out to sed and add this info to the penultimate line of .bash_history (race conditions shouldn't be a problem if only one human is using the same account), but as the history file grows very large this can cause a visible lag. Alternately I could write a special-purpose command which jumps directly to the end of the file, but it would be really nice if bash just did this for you. Thanks, -- Alex
Re: feature request: configurable history timestamps
On Sun, Dec 18, 2011 at 3:26 AM, Chet Ramey wrote: > On 12/11/11 1:13 AM, Alex Shinn wrote: > >> I had initially been confused by the HISTTIMEFORMAT >> variable thinking it could be used to change what was >> written to the history file, rather than the output of the >> history command. >> >> Obviously it would have to be a separate variable, but >> the ability to add extra info to the history file would be >> very useful to me. Given the pid and pwd you can >> effectively track sessions, and know where you invoked >> a command in addition to when. >> >> As a simple change, just statically appending the bash >> pid such that the history file looks like: >> >> #1323582935 217 >> command >> >> would enable constructing a session and inferring the >> pwd by checking for cd/pushd/popd commands (assuming >> no other aliases or scripts are used to chdir). > > One question is whether or not this would be of general interest, since > any user-specified text to append to the timestamp would have to come > after the timestamp and be more-or-less ignored by the history code proper. > (and the timestamp would have to be inserted unconditionally). What's the > use case? Third-party forensics? You can already use HISTFILE to break > out history by session, so this would only be worth it if you insisted on > using a single history file for all shell sessions. Yes, I do insist on this - I want ^R and history search to be able to search all my sessions. -- Alex
exec 10>&- does not close fd 10
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux doe 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 3.1
Patch Level: 7
Release Status: release
Description:
While the exec command can be used with the special redirection
expression to close any of file descriptors 0-9, it does not work with
file descriptors of two or more digits. Other redirection syntax
*does* work with these, so it seems unlikely this is intentional.
Repeat-By:
lsof-self() { lsof -p $$ || ls -l /proc/self/fd; }
exec 9>/dev/null 10>/tmp/bash-exec-fd-bug
lsof-self # to see that fd 9 and 10 are open
exec 9>&- 10>&-
lsof-self # to see that fd 9 is now closed, but 10 is still open
# at this point, a bash-3.0 shell has (correctly) closed fds 9 & 10
# but a bash-3.1 shell has only close fd 9; but other redirection with
# double-digit-descriptors does work with bash-3.1, as shown below:
exec 11>&10-
lsof-self # to see that fd 10 (/tmp file) has moved to fd 11
exec 9>&11-
lsof-self # to see that fd 11 (/tmp file) has moved to fd 9
exec 9>&- # now we can close the fd!
Fix:
I don't have a fix for this, but I do have a workaround, which is to
use the file descriptor move operation to move the fd to a single-digit
descriptor number, and then close that, as shown at the end. The only
catch is that *moving* an already closed fd is an error, while closing
an already closed fd is not, so I have to make sure it is open (using
/proc/self/fd/) first.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
globstar syntax
Should the globstar (**) syntax allow for partial parameter matching
(i.e. **.c to find all *.c files in the current directory and its sub-
directories)?
Currently this can be implemented like this:
for i in **; do if [[ ${i} =~ \.c$ ]]; then ; fi; done
It would be pleasantly convenient if this were condensed to:
for i in **.c; do ; done
Or even:
**.c
With 'shopt -s globstar', I think that the syntax:
**/*.c
accomplishes the same goal, but I'm not sure it's 'correct'.
Thanks!
Re: globstar syntax
Thanks Chet, and everyone who has contributed.
Re: bash 3.2 and bash 4.0 (RC1) fail to build statically
2009/2/2 Chet Ramey : > I was able to successfully compile and link after configuring > --enable-static-link --without-bash-malloc (there's some problem with libc > and the bash malloc when you try a static link). Yep that works for me too on anything except Debian GNU/Linux. On that I get failure to link. If I figure out what's wrong in that specific case I'll let you know =) For now it builds just fine on F10 (32-bit and 64-bit) as well as Gentoo Linux (32-bit and 64-bit) which is sufficient. Cheers for the response. Much appreciated. Alex
mapfile usage
Can someone please explain how 'mapfile' should be used? I am trying:
cat file.txt | mapfile
for i in ${MAPFILE};do echo $i; done
and I see no output. I've tried adding the -t option to strip
trailing newlines. If I use the following command:
mapfile -u file.txt
I get the error:
bash: mapfile: file.txt: invalid file descriptor specification
Exit 1
This is sad... Any suggestions?
Re: mapfile usage
On Feb 4, 2:59 pm, Stephane CHAZELAS
wrote:
> 2009-02-4, 10:50(-08), Alex Reed:
>
> > Can someone please explain how 'mapfile' should be used? I am trying:
>
> > cat file.txt | mapfile
> > for i in ${MAPFILE};do echo $i; done
>
> > and I see no output.
>
> mapfile would be run in a subshell.
>
> Try mapfile < file.txt
>
> Note that the for loop syntax above is zsh's, not bash's.
>
> In bash (and ksh from which it derives), you need:
>
> for i in "${mapfi...@]}"; do echo "$i"; done
>
> >I've tried adding the -t option to strip
> > trailing newlines. If I use the following command:
>
> > mapfile -u file.txt
>
> > I get the error:
>
> > bash: mapfile: file.txt: invalid file descriptor specification
> > Exit 1
>
> [...]
>
> The "help mapfile" is a bit confusing here:
>
> help> mapfile: mapfile [-n count] [-O origin] [-s count] [-t] [-u fd] [-C
> callback] [-c quantum] [array]
> help> Read lines from a file into an array variable.
> help>
> help> Read lines from the standard input into the array variable ARRAY,
> or from
>
> Looks like the first "Read lines..." was not intentional.
>
> Now I wonder why a new builtin was created for that. It looks
> like the same could have been done with very few lines of bash
> code. Also the name is misleading at it suggests writing to the
> array should write to the file (as the $mapfile associative
> array in zsh), extending the "read" builtin for that would have
> seemed more natural to me.
>
> Also, it looks like it should guard against
> seq 5 | mapfile -C echo -c0
>
> That command above cannot be interrupted with
>
> $ seq 5 | mapfile -C echo -c1
> 1
> 2
> 3
> 4
>
> I would have expected 1,2,3,4,5 above from the "help mapfile"
> description.
>
> mapfile <&-
>
> hangs as well (tight loop as well, cannot be interrupted).
>
> --
> Stéphane
Nice. Thank you!
Errors when patching bash4.0
Hello,
I've downloaded and decompressed the bash-4.0 tarball, and downloaded
bash40-001 through bash40-028 into a subdirectory bash-4.0/patches,
using:
bash $ tar xzvf bash-4.0.tar.gz
bash $ cd bash-4.0
bash-4.0 $ mkdir patches
bash-4.0 $ # line breaks added for clarity to you, the reader
for i in {001..028}; do
echo "### OPERATING ON PATCH $i ###"
lynx -dump -width=1000
http://ftp.gnu.org/gnu.bash/bash-4.0-patches/bash40-$i
> patches/bash40-$i;
patch -p0 < patches/bash40-$i
done
Now I start to get some nasty output.
### OPERATING ON PATCH 001 ###
patching file parse.y
Hunk #1 succeeded at 2932 with fuzz 2.
Hunk #2 succeeded at 3276 with fuzz 1.
Hunk #5 FAILED at 3442.
1 out of 4 hunks FAILED -- saving rejects to file parse.y.rej
patching file patchlevel.h
...
...
...
At least one "hunk" fails on every patch file. What am I doing wrong?
Thanks,
-Alex
Re: Errors when patching bash4.0
On Jul 22, 4:09 pm, Bob Proulx wrote: > Alex Reed wrote: > > At least one "hunk" fails on every patch file. What am I doing wrong? > > Hmm... Works for me. Here is a trace of the important bits. > > $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz > $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz.sig > > $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001 > $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001.sig > > $ gpg bash-4.0.tar.gz.sig > gpg: Signature made Mon 09 Mar 2009 08:32:40 AM MDT using DSA key ID > 64EA74AB > gpg: Good signature from "Chet Ramey " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 7C01 35FB 088A AF6C 66C6 50B9 BB58 69F0 64EA 74AB > > $ gpg bash40-001.sig > gpg: Signature made Mon 09 Mar 2009 08:32:40 AM MDT using DSA key ID > 64EA74AB > gpg: Good signature from "Chet Ramey " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 7C01 35FB 088A AF6C 66C6 50B9 BB58 69F0 64EA 74AB > > The key point there with a good signature we know that the patches are > not corrupted. The signature step would detect this. The key is the > same key used on all of the patches. The patches match those posted > to the mailing list. Those patches probably came from Chet. :-) > > $ tar xzf bash-4.0.tar.gz > $ cd bash-4.0 > $ patch -p0 < ../bash40-001 > patching file parse.y > patching file patchlevel.h > > $ patch --version > patch 2.5.9 > > Works for me. > > $ sha1sum bash40-001 bash-4.0.tar.gz > dc47d547bec938afcd7b382816fec84077f3412f bash40-001 > 2bbed30879f9f424c091a846a48111c27d0b2370 bash-4.0.tar.gz > > I would check that your downloaded patch files are not corrupted for > some reason. I would check that line endings are respected and for > similar things that might confuse things. I am not familiar with > using lynx as a downloader although I am sure it is fine for the > task. But at a guess I would think that would be the place to start > to look for problems. > > Bob You make a good point in the last paragraph - lynx "should" work (but doesn't). Considering I was having to specify a maximum line-length, lynx (I suppose) was still botching the files. After using wget in place of lynx (with the appropriate proxy flag changes) everything patched a-okay. Thanks! -Alex
Re: wait with trap SIGCHLD: different behaviour in 3.2 and 4.0
Hi! On Sun, Sep 27, 2009 at 11:06:43PM -0400, Chet Ramey wrote: > > Description: > > Looks like 'wait' command in bash-4 is broken: if used together > > with 'trap myhandler SIGCHLD' the 'wait' (without params) exit > > just after receiving first child exit, instead of waiting for all > > childs exit. > Posix requires this behavior. > > "When the shell is waiting, by means of the wait utility, for asynchronous > commands to complete, the reception of a signal for which a trap has been > set shall cause the wait utility to return immediately with an exit status > >128, immediately after which the trap associated with that signal shall be > taken." > > This was reported as a bug against bash-3.2. Cool. Is there any hint/doc/faq/how-to implement old behaviour, i.e. wait until all children of current bash process will exit? P.S. I've not seen this information in 'help wait' or 'man bash' - is this current 'correct' behaviour is documented? -- WBR, Alex.
parsing error with heredoc and command substitution
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux alexk 2.6.32-gg173-generic #gg173 SMP Wed Jun 23 05:24:15 UTC 2010 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: The following script used to work in bash 3.2 but does not work with bash 4.x (I tried 4.0, 4.1.5, and 4.1.7) -- #!/bin/bash a=$(/bin/cat << EOF | wc -l a b EOF ) - /tmp/bug.sh: line 3: unexpected EOF while looking for matching `)' /tmp/bug.sh: line 8: syntax error: unexpected end of file The following works correctly (changed /bin/cat to cat): -- #!/bin/bash a=$(cat << EOF | wc -l a b EOF ) - and so does this (removed | wc -l): -- #!/bin/bash a=$(/bin/cat << EOF a b EOF ) -
Simple sleep scripts causes SEGFAULT
I couldn't get bashbug to send this, so I manually am emailing it.
"/usr/bin/bashbug: rmail: not found"
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux minmus 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19
17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 48
Release Status: release
Description:
Segmentation fault. I'm honestly not sure why. I was using batsh to
make a simple script. When I ran it generated a segfault. The segmentation
fault DOES NOT occur if "sleep" is replaced with "echo".
I also ran it on "GNU bash, version 4.4.12(1)-release
(x86_64-redhat-linux-gnu)" using codingground (
https://www.tutorialspoint.com/execute_bash_online.php) the same issue
occurred.
Repeat-By:
Run the following script (assuming you trust me lol):
function sleep {
local dur
dur="$1"
# if replaced with "echo" no segfault.
sleep ${dur}s
}
"sleep" $((5))
Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
Hi All, I’m an Ethical Hacking student at Coventry university and while doing some exploit development on my Linux boxes I stumbled across a bug in the bash 4.4.12(1) - release. In order to trigger the bug I executed the command *`*cat sploit.buf*`* where sploit.buf is a just over 2GB file of ‘A’ characters. When this command is executed the bash terminal crashes with the following error “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error message appears to vary on different Linux distros. On Kali 2017.2 64 bit the error message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate 18446744071562067968 bytes (4296613888 bytes allocated)”. This bug may present a potential security risk as a malicious user may be able to crash a users bash session by tricking them into executing a malicious bash script. I will be adhering to the ICS-CERT Vulnerability Disclosure Policy and look forward to further discussing and resolving this bug Regards, Alex
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
Thank you for taking the time to respond to my email. I accept that this is likely not a security issue outside of being a social engineering attack, but the buggy behaviour that i'm curious about is that in each case the allocation should only have been of 2147483647 bytes in size (the size of the file i was using cat on). but instead, according to the error, bash had attempted to allocate far more memory than was required which is what caused the crash. for example the Kali example attempted to allocate 18446744071562067968 bytes or roughly 18446744071 GB of memory. Its also worth noting that the Kali example should have been able to have allocated more than enough memory to hold the 2GB file since it was able to allocate up to 4296613888 bytes of heap memory when it crashed. On Tue, Nov 7, 2017 at 2:21 PM, Eduardo Bustamante wrote: > On Tue, Nov 7, 2017 at 5:58 AM, Alex Nichols > wrote: > [...] > > In order to trigger the bug I executed the command *`*cat sploit.buf*`* > > where sploit.buf is a just over 2GB file of ‘A’ characters. When this > > command is executed the bash terminal crashes with the following error > > “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes > > (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error > message > > appears to vary on different Linux distros. On Kali 2017.2 64 bit the > error > > message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate > > 18446744071562067968 bytes (4296613888 bytes allocated)”. > [...] > > This is a normal memory exhaustion problem. You are asking bash to allocate > over 2 GiB of heap memory, and your system is unable to provide that amount > of memory. > > > This bug may present a potential security risk as a malicious user may be > > able to crash a users bash session by tricking them into executing a > > malicious bash script. > [...] > > This is not a security issue. If you can trick a user into running this > script, > why stop there? Why not instead encrypt the file system and hold it for > ransom? or delete it? Or steal credentials by uploading ~/.netrc, > ~/.ssh/id_rsa, > ~/.aws/credentials, ... > > You will find this problem in any program that allocates memory > dynamically. > Try allocating a >2 GiB in python, ruby, perl, php, awk, ... >
'bash +o history' to disable history has no visible effect as of v4.4
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux arch-desktop 5.2.7-zen1-1-zen #1 ZEN SMP PREEMPT Wed Aug 7 01:55:52 UTC 2019 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 9 Release Status: release Description: `bash +o history` no longer works as expected - that is, it doesn't disable history - both in-memory history and saved-to-file history. Occurs in bash 4.4 and later. Rudimentary test results: 4.2.53(1)-release : pass 4.3.0(1)-release : pass 4.3.30(1)-release : pass 4.3.48(1)-release : pass 4.4.0(1)-release : fail 4.4.12(1)-release : fail 4.4.18(1)-release : fail 5.0.0(1)-release : fail 5.0.9(1)-release : fail - Alex Kerzner Repeat-By: ~~~ # Long way, but potentially easier to implement a test case for bash +o history # attempt to start a new shell with history disabled set -o | grep history # See that history is still on ~~~ ~~~ # Short way, a sweet and simple method bash +o history -i -c 'set -o | grep history' ~~~ In both cases: Expected: 'historyoff' printed; command not sent to history file (if shell is interactive, etc.) Actual: 'historyon' printed; command sent to history file (if shell is interactive, etc.)
Man page typo: "abd"
I hope this is the right place to fix it. Thanks for bash. :) Cheers Alex >From 1ff12f30e83762bea2ca0c1b09c240ab2d1086ca Mon Sep 17 00:00:00 2001 From: Alex Schroeder Date: Fri, 24 Apr 2020 19:51:25 +0200 Subject: [PATCH] Bash-5.0 patch 18: fix typo in the man page --- doc/bash.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bash.1 b/doc/bash.1 index e6cd08db..4ccf1001 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -4498,7 +4498,7 @@ rules above. Conditional expressions are used by the \fB[[\fP compound command and the \fBtest\fP and \fB[\fP builtin commands to test file attributes and perform string and arithmetic comparisons. -The \fBtest\fP abd \fB[\fP commands determine their behavior based on +The \fBtest\fP and \fB[\fP commands determine their behavior based on the number of arguments; see the descriptions of those commands for any other command-specific actions. .PP -- 2.20.1
Re: [PATCH] Support configurable mode strings in prompt
On Thursday, September 4, 2014 5:22:58 AM UTC-6, Dylan Cali wrote: > Hi Chet, > > Just curious if it will be possible to merge this enhancement? > > Thanks, > Dylan This is what it looks like right now. It's still really helpful as is, but it doesn't really fit in with the theme I was going for :) http://i.imgur.com/xXpOJqe.png
Re: [PATCH] Support configurable mode strings in prompt
On Thursday, September 4, 2014 7:00:16 AM UTC-6, Chet Ramey wrote: > On 9/4/14, 7:22 AM, Dylan Cali wrote: > > Hi Chet, > > > > Just curious if it will be possible to merge this enhancement? > > I haven't looked at it yet. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ I hope this gets merged in soon. I love the bash vi mode and I love the realtime mode indicator that we now have with show-mode-in-prompt. If I could customize that portion of my command line I could add that portion of the prompt in a much more stylized way. If I could make the color change and make it say "insert", "visual", and "normal" as the mode changes, that would be pretty cool.
Re: says TRACE: pid 1562: shell_getc: bash_input.location.string = `'
thanks && cc list On Mon, Feb 15, 2021, 15:04 Chet Ramey wrote: > On 2/15/21 8:57 AM, Alex fxmbsw7 Ratchev wrote: > > i had yet a couple of trace msges, this one s new > > any big meaning ? > > Nope, it's informational for me. You see it because you're running a > debug version. > > -- > ``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: Behaviour of test -v with assoc array and quote character in key
what, sorry, mailing stuff isnt much clear to me, ... its not possible to have a var=\'\] ; assoc[$var] ? On Mon, Feb 22, 2021 at 5:48 PM Chet Ramey wrote: > On 2/15/21 1:28 PM, Daniel Gröber wrote: > > > On Mon, Feb 15, 2021 at 09:11:48AM -0500, Chet Ramey wrote: > >> `test' is always going to be problematic here because, as a shell > builtin, > >> its arguments undergo a round of word expansions before it's invoked. > It's > >> difficult to reliably detect the closing bracket in an array subscript > as a > >> result, even if the array subscript expansion didn't perform any > expansions > >> on its own. (Consider what would happen if $1 were `]'). > > > > You're absolutely right, I didn't consider the ']' case at all! That > would > > obviously break. So indeed this just user-error then and not really a > bug. > > Well, it's less than ideal. This is why I introduced the assoc_expand_once > option, but as many folks on here will tell you, it's not a perfect > solution. This is one of the cases where it's not. > > I think I have a better way to do it, one that doesn't require using an > extra level of quoting or assoc_expand_once, but I'm not ready to commit > anything yet, and builtins like test/[ and let will always cause problems. > > 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: Behaviour of test -v with assoc array and quote character in key
yeah i thought so.. thanks On Tue, Feb 23, 2021 at 12:52 PM Léa Gris wrote: > Le 23/02/2021 à 12:17, Alex fxmbsw7 Ratchev écrivait : > > what, sorry, mailing stuff isnt much clear to me, ... its not possible to > > have a var=\'\] ; assoc[$var] ? > > You can if assoc is declared an associative array before: > > > $ (LANG=C; unset var assoc; var=\'\]; assoc[$var]=hello; typeset -p > assoc) > > bash: ']: syntax error: operand expected (error token is "']") > > but: > > > $ (LANG=C; unset var assoc; var=\'\]; declare -A assoc; > assoc[$var]=hello; typeset -p assoc) > > declare -A assoc=(["']"]="hello" ) > > > > > -- > Léa Gris > > >
another mail try for the hang 100% cpu alias run bug
i cannot exclude it'd be my bug ( again ) but i dunno i have no choise than trying to present the hanger to you folks to fix it if you'd unpack ogt1.tgz ull find ogt1/ and some dirs and scripts, the code from the other paste didnt change, i just try to explain it so you dont have a that hard time tyring to figure this issue ogt1/ogt is the main linker script that binds via aliases/+alias aliases from file named content, and +kw for assoc array keywords to eval system then ok till now, then i go test the aliases/kws code that evals per keyword, but it hangs right after the first line that says some_value=-1 what would follow is the while [[ -v some_var[++some_value ]] loop for processing ... the =-1 appears, then hangs, no other set -x output included is also to the archive the kws alias code, maybe you can see an error, maybe not, :)) to explain the assoc array system a bit deeper: s=subsep ; namespace=empty arr[ kw ] should expand to an id useable for: arr[ ] = value and in kws simply eval the code part its not much finished but its very far ogt1.tgz Description: application/compressed-tar kws Description: Binary data
addition to the hung 100% cpu bug, just some strace output
..based on it, c pros, you can prolly see clearly whats wrong
it like mmaps more and more memory beeing slower every run
) = 3
write(2, "++ [[ -v addkw[++addkw_i] ]]\n", 29++ [[ -v addkw[++addkw_i] ]]
) = 29
write(2, "++ dat[$nspace${SUBSEP}kw$SUBSEP"..., 53++
dat[$nspace${SUBSEP}kw$SUBSEP${addkw[addkw_i]}]=1
) = 53
write(2, "++ [[ -v addkw[++addkw_i] ]]\n", 29++ [[ -v addkw[++addkw_i] ]]
) = 29
write(2, "++ [[ -v addkwf[++addkwf_i] ]]\n", 31++ [[ -v addkwf[++addkwf_i]
]]
) = 31
write(2, "+ kws=(metest)\n", 15+ kws=(metest)
)= 15
write(2, "+ kws_i=-1\n", 11+ kws_i=-1
)= 11
brk(0x5626989a4000) = 0x5626989a4000
brk(0x5626989a5000) = 0x5626989a5000
brk(0x5626989a7000) = 0x5626989a7000
brk(0x5626989ab000) = 0x5626989ab000
brk(0x5626989b3000) = 0x5626989b3000
brk(0x5626989c3000) = 0x5626989c3000
brk(0x5626989e3000) = 0x5626989e3000
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364fedf000
brk(0x5626989c3000) = 0x5626989c3000
mmap(NULL, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364fe5f000
munmap(0x7f364fedf000, 262144) = 0
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364fd5f000
munmap(0x7f364fe5f000, 524288) = 0
mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364fb5f000
munmap(0x7f364fd5f000, 1048576) = 0
mmap(NULL, 4194304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364f75f000
munmap(0x7f364fb5f000, 2097152) = 0
mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f364ef5f000
munmap(0x7f364f75f000, 4194304) = 0
mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f364df5f000
munmap(0x7f364ef5f000, 8388608) = 0
mmap(NULL, 33554432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f364bf5f000
munmap(0x7f364df5f000, 16777216)= 0
mmap(NULL, 67108864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f3647f5f000
munmap(0x7f364bf5f000, 33554432)= 0
mmap(NULL, 134217728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f363ff5f000
munmap(0x7f3647f5f000, 67108864)= 0
mmap(NULL, 268435456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f362ff5f000
munmap(0x7f363ff5f000, 134217728) = 0
mmap(NULL, 536870912, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f360ff5f000
munmap(0x7f362ff5f000, 268435456) = 0
^C--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
strace: Process 10181 detached
the 100% hanger..
sorry for changing topics, i try .. its still the same topic code the code (error, bug) is included in 'kws' which is supposed to eval set keywords i do kws=( something ) kws it hangs i do kws=( something ) ; kws it hangs i do only kws ( when the var is set already from last time ) it processes normally i added by some irc bug chat a printf after the first line which is var definement sorry, second: in aliases its first line be var assignments, second then commands, and ends mostly on purpose with newline and a space i added a printf.. the hung versions never seen that printf, they stuck out the bug is somewhere in alias var assignment codes kws Description: Binary data
the 100% hanger..
so i fixed the code to have a newline before using the kws alias
it, to my half surprise, works perfectly, it displays the metest keyword
right, but on the second [[ -v arr[elem] ]] check it hangs, probably brk
ing few then mmaping and unmapping much, == bug ? :)
bash-5.1# bash ogt_demo
+ bash ogt_demo
current keyword 1 of 1 in total ( -> metest <- ) ( code :
printf 'current keyword %d of %d in total ( -> %s <- ) ( code : %s )\n'
$[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
)
^C
bash-5.1#
+ kws_i=-1
+ [[ -v kws[++kws_i] ]]
+ kws_kw=metest
+ kws_p1=$'\034'
+ kws_id=1
+ kws_p2=$'\0341\034'
+ kws_code='
printf '\''current keyword %d of %d in total ( -> %s <- ) ( code : %s
)\n'\'' $[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
'
+ [[ ! -n
printf 'current keyword %d of %d in total ( -> %s <- ) ( code : %s )\n'
$[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
]]
+ (( 0 < ( kws_take = 0 ) ))
+ kws_args=()
+ eval -- '
printf '\''current keyword %d of %d in total ( -> %s <- ) ( code : %s
)\n'\'' $[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
'
++ printf 'current keyword %d of %d in total ( -> %s <- ) ( code : %s )\n'
1 1 metest '
printf '\''current keyword %d of %d in total ( -> %s <- ) ( code : %s
)\n'\'' $[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
'
current keyword 1 of 1 in total ( -> metest <- ) ( code :
printf 'current keyword %d of %d in total ( -> %s <- ) ( code : %s )\n'
$[1+kws_i] ${#kws[@]} "$kws_kw" "$kws_code"
)
+ [[ -v kws[++kws_i] ]]
^C
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
pipe([3, 4])= 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT TERM CHLD], [], 8) = 0
clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process 11639
attached
, child_tidptr=0x7fbca46aca10) = 11639
[pid 11633] rt_sigprocmask(SIG_SETMASK, [],
[pid 11639] getpid(
[pid 11633] <... rt_sigprocmask resumed>NULL, 8) = 0
[pid 11639] <... getpid resumed>) = 11639
[pid 11633] rt_sigaction(SIGCHLD, {sa_handler=0x55c5974b0f70, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbca46ead60},
[pid 11639] close(255
[pid 11633] <... rt_sigaction resumed>{sa_handler=0x55c5974b0f70,
sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbca46ead60},
8) = 0
[pid 11639] <... close resumed>)= 0
[pid 11633] close(4)= 0
[pid 11639] rt_sigprocmask(SIG_SETMASK, [],
[pid 11633] rt_sigprocmask(SIG_BLOCK, [INT],
[pid 11639] <... rt_sigprocmask resumed>NULL, 8) = 0
[pid 11633] <... rt_sigprocmask resumed>[], 8) = 0
[pid 11639] rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60},
[pid 11633] read(3,
[pid 11639] <... rt_sigaction resumed>{sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGTTOU, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, {sa_handler=SIG_IGN,
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbca46ead60},
{sa_handler=0x55c5974b0f70, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART,
sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGCHLD, {sa_handler=0x55c5974b0f70, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbca46ead60},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART,
sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] rt_sigaction(SIGINT, {sa_handler=0x55c5974d18a0, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbca46ead60}, 8) = 0
[pid 11639] dup2(4, 1) = 1
[pid 11639] close(4)= 0
[pid 11639] close(3)= 0
[pid 11639] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 11639] openat(AT_FDCWD, "/root/ogt1/keywords/metest", O_RDONLY) = 3
[pid 11639] read(3, "\nprintf 'current keyword %d of %"..., 4096) = 119
[pid 11639] write(1, "\nprintf 'current keyword %d of %"..., 119
[pid 11633] <... read resumed>"\nprintf 'current keyword %d of %"..., 512)
= 119
[pid 11639] <... write resumed>)= 119
[pid 11633] read(
the 100% hanger..
by second [[ -v arr[elem] ]] n after hangs i mean i have two parts in this
one is the kws index array with keywords to parse, the other is kws the
alias that parses the ${kws[@]} arr
so for the first element there in the last mail it worked
and displayed the content of the alias, as the code
but on the second which should fail cause there is only 1 elem in $kws[ it
hangs , with brks and memmapps growing rapidly
peace, i analyzed well i think
please :))
metest
Description: Binary data
the 100% hanger..
the last analyzement of the weirdness is arr=( .. ) _alias_ then it at least runs thru one arr[0], which is set, and evals the code right and working, however on the next [[ -v arr[1] ]] ( empty ) check it hangs if i dont write the newline after arr=( .. ) for like usual, i get hung on already arr[0]
is it normal that set -x unset commands dont display special chars in the content
but they get unset right, just doesnt display em
i have stuff with $'\34' separator and in set -x output the text is just
flat for the unset
+ unset 'dat[kwmetest]' 'dat[1kw1]' 'dat[1take]' 'dat[1code]'
code includes
minuskws_p1=$nspace$SUBSEP$minuskws_id$SUBSEP \
minuskws_p2=$nspace${SUBSEP}kw$SUBSEP
is there a way to autocomplete ( the show vars matching to str ) for assoc keys ?
say i have assoc[ ] i want to ${!assoc[begin*]}
Re: is it normal that set -x unset commands dont display special chars in the content
i still dont understand, ( you speak more special english than code ), why unset wont display the special chars, but then i suppose its not much of a bug .. ? On Mon, Mar 1, 2021 at 1:19 AM Chet Ramey wrote: > On 2/28/21 6:19 PM, k...@plushkava.net wrote: > > >> The check for shell special characters, which results in single quoting, > >> comes before whether there are any characters that would require ANSI-C > >> quoting. This is not specific to unset. > > > > In fairness, I don't think it's strictly incorrect to say that the > outcome > > is different "for" one of two commands used in a trivial example. I was > > only attempting to clarify the circumstances that begat the original > question. > > I understand. The point is that it's faulty reasoning to say that it's a > difference between two commands when there are more differences than the > (builtin) command name itself. It's one of the first rules of > troubleshooting: reduce the number of variables between cases. > > In this case, running `:' and `unset' with the same arguments would have > shown that that difference was in how the arguments are treated, not the > builtin itself. > > -- > ``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: is it normal that set -x unset commands dont display special chars in the content
it just displays the wrong data completly, the special chars cutted off, .. .. On Mon, Mar 1, 2021 at 10:28 AM Alex fxmbsw7 Ratchev wrote: > i still dont understand, ( you speak more special english than code ), why > unset wont display the special chars, but then i suppose its not much of a > bug .. ? > > On Mon, Mar 1, 2021 at 1:19 AM Chet Ramey wrote: > >> On 2/28/21 6:19 PM, k...@plushkava.net wrote: >> >> >> The check for shell special characters, which results in single >> quoting, >> >> comes before whether there are any characters that would require ANSI-C >> >> quoting. This is not specific to unset. >> > >> > In fairness, I don't think it's strictly incorrect to say that the >> outcome >> > is different "for" one of two commands used in a trivial example. I was >> > only attempting to clarify the circumstances that begat the original >> question. >> >> I understand. The point is that it's faulty reasoning to say that it's a >> difference between two commands when there are more differences than the >> (builtin) command name itself. It's one of the first rules of >> troubleshooting: reduce the number of variables between cases. >> >> In this case, running `:' and `unset' with the same arguments would have >> shown that that difference was in how the arguments are treated, not the >> builtin itself. >> >> -- >> ``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: is it normal that set -x unset commands dont display special chars in the content
oh i see, thank you big time for pointing it out so good
:))
On Mon, Mar 1, 2021 at 11:22 AM felix wrote:
> On Sun, Feb 28, 2021 at 10:32:13PM +, k...@plushkava.net wrote:
> > Why not indeed. However, I think that I'm able to decipher this.
> >
> > $ declare -A map; key=$'foo\34bar'; map[$key]=
> > $ set -x
> > $ : "$key"
> > + : $'foo\034bar'
> > $ unset "map[$key]"
> > + unset 'map[foobar]'
> >
> > For the unset command, xtrace elects to emit the (non-printable) FS
> > character verbatim rather than employ the ANSI-style notation.
> Presumably,
> > this led to the conclusion that bash doesn't "display em".
>
> I agree:
>
> $ declare -A map; key=$'foo\34bar'; map[$key]=
> $ exec {BASH_XTRACEFD}> >(sed -ue 's/\o34/<<\\34>>/')
> $ set -x
> $ : "$key"
> + : $'foo\034bar'
> $ unset map["$key"]
> + unset 'map[foo<<\34>>bar]'
>
>
> --
> Félix Hauri - - http://www.f-hauri.ch
>
>
>
Re: uname lead to embed code execution
as a side info, only interpretation of vars in builtins may be affected, eg
solution as written : single quote the '$ley', on the other side
${var[$faulty_key]} doesnt eval it, only args usage as for declare unset
and [[ -v
.. maybe ..
On Mon, Mar 1, 2021 at 3:40 PM Greg Wooledge wrote:
> felix (fe...@f-hauri.ch) wrote:
>
> > There it is:
> >
> > $ declare -A map; key='foo$(uname >/dev/tty)bar'; map[$key]=
> > $ echo map["$key"]
> > map[foo$(uname >/dev/tty)bar]
> > $ echo ${map["$key"]}
> >
> > $ unset map["$key"]
> > Linux
>
> Yeah, it's sad but true. I've just added a whole (short) section on
> associative array index multiple expansions to my CodeInjection page.
>
> https://mywiki.wooledge.org/CodeInjection
>
>
doesnt interate the array anymore, what am i doing wrong
i usually interate thru indexed arrays as, i=-1, while [[ -v arr[++i] ]],
but it suddenly stopped
maybe cause i switched to in-functions than aliases use
bash-5.1# cat int.fail
int() {
declare -a int
declare i=-1 now
while [[ -v int[++i] ]] && now=${int[i]} ; do
printf %s\\n "$now"
done
}
int=( a b c )
int
bash-5.1# bash int.fail
bash-5.1#
again it used to work this way, just maybe with functions not
is it a a bash bug ? is it my bug ?
re: doesnt interate the array anymore, what am i doing wrong
this is what i tried to achieve, but right it still fails: # foo=( 0 1 2 ) i=-1 ; while [[ -v foo[++i] ]] ; do : ; done ; printf $i ogt: 3 just in functions not .. .. ?
re: doesnt interate the array anymore, what am i doing wrong
i thought i tested, to 'shadow' the array to local to make it expandable in
the function
but it seems its empty
so declare -a arr=( "${arr[@]}" )
as is otherwise empty
any better idea ?
re: doesnt interate the array anymore, what am i doing wrong
and as last note to end this thread: var=foo func leaves 'declare var ;' inside func be still 'foo' while var=foo ; func does make it empty peace, thanks, swfun
Re: doesnt interate the array anymore, what am i doing wrong
yea well i posted in a later post, locally declared vars are empty excepts
they are given on the function calling line, just like local vars, hm
the different names is not so a good idea but ill think
thank you much anyway :))
On Mon, Mar 8, 2021 at 2:25 AM Greg Wooledge wrote:
> Alex fxmbsw7 Ratchev (fxmb...@gmail.com) wrote:
> > bash-5.1# cat int.fail
> > int() {
> > declare -a int
>
> You've declared a local array named "int" which has nothing in it.
>
> This is inside a function named "int".
>
> > declare i=-1 now
> >
> > while [[ -v int[++i] ]] && now=${int[i]} ; do
> > printf %s\\n "$now"
> > done
> > }
>
> You're iterating on the empty local array.
>
> >
> > int=( a b c )
> > int
>
> You also have a global array named "int".
>
> I suggest that you use different names for your stuff. This will help
> you avoid a lot of problems. Having a global variable, a local variable,
> and a function all sharing the same name (and a name which is actively
> *misleading* given that one of the arrays does not, in fact, contain
> integer values) is not helping you.
>
>
Re: doesnt interate the array anymore, what am i doing wrong
oh i see, a bit of my fault, me noob with web mail and mailing lists im sorry i hope for better up soon On Mon, Mar 8, 2021 at 2:33 AM Eli Schwartz wrote: > On 3/7/21 8:24 PM, Alex fxmbsw7 Ratchev wrote: > > and as last note to end this thread: > There is no thread. > > There are, in fact, four threads. I suspect you're using gmail.com's web > client (??), which does not generate working emails many times. > > Specifically, for whatever reason, all your emails are not being sent as > responses to other emails. > > -- > Eli Schwartz > Arch Linux Bug Wrangler and Trusted User > >
declare -n next=arr[++elem] == nowork ? [[ -v
[msg(shbot)] # foo() { declare -a foo=( "$@" ) ; declare i=-1 ; declare -p
foo ; declare -n next=foo[++i]
now=foo[i] ; while [[ -v next ]] ; do : $now ; done ; printf -- $i ; } ;
foo '' 1 2 3
[shbot(~shbot@37.139.2.101)] declare -a foo=([0]="" [1]="1" [2]="2" [3]="3")
[shbot(~shbot@37.139.2.101)] -1
any way to make it work ? i think i remember that it used to work at least
once for me ..
Re: declare -n next=arr[++elem] == nowork ? [[ -v
thank you for your answer
i have a question about [[ -v $next ]] i havent tried but you say it works
it would ? expand $next but wont it then check '[[ -v ]]'
and fail ?
ill benchmark the usage of : $next ; before [[ -v now, if its minimal its
all fine i can use
i just remember it used to work
for the [[ -v arr[++elem] ]] style i do cause i can add in the loop to the
array and it continues over the new elements, till no more
also i think speed wise its very good, not so sure anymore lately
i also have another this-same-declare issue with a more complex data
structure
i have an assoc structure of two types in one array var
[$id] mainly, which is coming from the same assoc array by [$keyword] (
with separators, i just simplified here )
the actual code looks around like:
KWS[$kwns$_S_$[++kwstot]]=$code KWS[$kwns$_S_$kwstot$_S_]=$takes
and in a loop per keyword ( $kw ) :
KWS[$kwns$_S_$_S_$kw]=$kwstot KWS[$kwns$_S_$kwstot$_S_$[++elem]]=$kw
$kwns is keyword_namespace, empty by default, i havent thought enough yet
technics to use it, however its a must
to eval the keywords:
while [[ -v kws[++i] ]] && kw=${kws[i]} t=$kwns$_S_ id=${KWS[$t$_S_$kw]}
code=${KWS[$t$id]} takes=${KWS[$t$id$_S_]} ; do
${code:+kwseval "$code" "${kws[@]:i:takes}" $[i+=takes]}
done
in fact i hope i send the three files as i am interested in an answer to:
'how can i declare -n right this issue'
each of the three files represents the content of the same-as-filename
named function
i made a linker to map aliases functions and assoc keywords from files to
.. bash .. ( id like to publish it but where, my bashhttpd isnt ready yet
but soon .. )
there are three different cases in the KWS assoc array
the ++id per +kw, which splits into two subelements, a 'code' key and a
'takes' key ( i didnt name em in the code anymore for only $_S_ $SUBSEP
$'\34' usage instead of long mixed text
and then theres the keyword in question entry that simply points to the id,
for the resolver to resolve to eval its code from the structure ..
i hope you didnt loose me too much yet
'how would i declare -n right the 3 (or 4) right ?'
On Mon, Mar 8, 2021 at 4:30 PM Chet Ramey wrote:
> On 3/7/21 9:36 PM, Alex fxmbsw7 Ratchev wrote:
> > [msg(shbot)] # foo() { declare -a foo=( "$@" ) ; declare i=-1 ; declare
> -p
> > foo ; declare -n next=foo[++i]
> > now=foo[i] ; while [[ -v next ]] ; do : $now ; done ; printf -- $i ; } ;
> > foo '' 1 2 3
> > [shbot(~shbot@37.139.2.101)] declare -a foo=([0]="" [1]="1" [2]="2"
> [3]="3")
> > [shbot(~shbot@37.139.2.101)] -1
>
> This report would have been better sent to help-bash.
>
> It's a misunderstanding about how namerefs work. They're not like cpp
> macros or some kind of recursive variable expansion; they make one variable
> name stand for another.
>
> In your example, you have next='foo[++i]'. When you run [[ -v next ]], the
> nameref gets expanded and the shell looks for a variable named 'foo[++i]'.
> This naturally fails, and the loop terminates.
>
> If you want to iterate through the values of the array, you're better off
> ditching namerefs and using `eval' or [[ -v $next ]] (if you want to
> maintain the same code structure) or some other construct. It would be much
> clearer to simply use a for loop to iterate from 0 to ${#foo[@]}.
>
> --
> ``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/
>
+kw
Description: Binary data
kwseval
Description: Binary data
kws
Description: Binary data
Re: declare -n next=arr[++elem] == nowork ? [[ -v
ill maybe make a post there, i just joined, other account was there but
seemfuly didint work out
about to ${#arr[@]} i forgot \\ didnt watch, i was backly thinking of
saving the var to an 'isend' var, but that was old style before that, i
wasnt using it cause i thought speedful backdraw, to always recheck the
#arr[@]
also if faulty code adds a non idx++ key that fails, of course thats not my
case but it comes to mind
on my todo list: more help-bash and benchmarks
thank you
On Tue, Mar 9, 2021 at 6:13 PM Chet Ramey wrote:
> On 3/8/21 11:19 AM, Alex fxmbsw7 Ratchev wrote:
> > thank you for your answer
> > i have a question about [[ -v $next ]] i havent tried but you say it
> works
> > it would ? expand $next but wont it then check '[[ -v
> ]]'
> > and fail ?
>
> Try it. -v will evaluate an array reference with a subscript to see if that
> particular element exists, but the general nameref resolution code does not
> (and should not) re-evaluate an array expansion.
>
> > ill benchmark the usage of : $next ; before [[ -v now, if its minimal
> its
> > all fine i can use
> > i just remember it used to work
>
> I doubt it, but it doesn't matter now.
>
> > for the [[ -v arr[++elem] ]] style i do cause i can add in the loop to
> the
> > array and it continues over the new elements, till no more
>
> Come on, so does iterating from 0 to ${#arr[@]}.
>
> > i also have another this-same-declare issue with a more complex data
> structure
>
> I think help-bash would be a good place for that discussion.
>
> --
> ``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: unsetting associative array executes commands
maybe implent a shopt -s no_expand_subshells
On Thu, Mar 11, 2021 at 9:20 PM Chet Ramey wrote:
> On 3/11/21 10:06 AM, Jason A. Donenfeld wrote:
> > This behavior is quite surprising:
>
> The idea is that array subscripts undergo a uniform set of expansions when
> they're used, no matter the context. Builtins already undergo word
> expansions as part of command execution. The result is double expansion
> in certain cases (there are more; this is a staple of discussion here on
> the list).
>
> You can use the `assoc_expand_once' shell option to reduce the number of
> expansions; it would have prevented the behavior you observed here, for
> instance. But it's not perfect, as many people on the list will tell you.
>
> >
> > $ declare -A blah
> > $ blah['$(DOESNOTEXIST)']=broken
> > $ for i in "${!blah[@]}"; do echo "$i"; done
> > $(DOESNOTEXIST)
> > $ for i in "${!blah[@]}"; do unset blah["$i"]; done
> > bash: DOESNOTEXIST: command not found
> > bash: unset: [$(DOESNOTEXIST)]: bad array subscript
>
>
> $ cat x1
> declare -A blah
> blah['$(DOESNOTEXIST)']=broken
> shopt -s assoc_expand_once
> for i in "${!blah[@]}"; do unset blah["$i"]; done
> declare -p blah
> $ ../bash-5.1-patched/bash ./x1
> declare -A blah=()
>
>
> --
> ``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/
>
>
'exec' produced internal code output instead of normal
i have no example to write here as this was past long the story was, i was coding a file server daemon, with socat, and i figured to use exec why not more exact more efficient but using it resulted sometimes output of code of the script in the output of the files removing exec made it work normally as supposed any known issue there ?
Re: 'exec' produced internal code output instead of normal
thank you sir
theres a misunderstanding tho
with exec i meant i exec socat instead of without exec
i may be able to reproduce it soon as i need to extend my softwares
peace
On Sun, Mar 14, 2021 at 3:37 PM Dale R. Worley wrote:
> > 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
> >> but using it resulted sometimes output of code of the script in the
> output
> >> of the files
> >> removing exec made it work normally as supposed
>
> One possibility is a typo, using "<<" rather than "<".
>
> Koichi Murase writes:
> > I don't know about `socat', but maybe it's just the file descriptor
> > collision. One needs to make sure that the file descriptor is not yet
> > used when a new file descriptor is opened. For example, in Bash
> > scripts, one should use the file descriptor 3--9 if you manually
> > specify it because the file descriptors larger than 9 may be already
> > used for other purposes.
>
> bash has the useful ability to select an unused file descriptor, such as
>
> exec {new_descr}>wherever
>
> That opens the file "wherever" for writing on some previously closed
> file descriptor and assigns the number to the variable "new_descr".
> After that you can do
>
>echo >&$new_descr
>
> etc.
>
> Dale
>
Re: 'exec' produced internal code output instead of normal
hi, well, i mean as first example around exec socat, not socats exec
directive ( which i used for script tho )
but i dont remember the circumstances
it was long ago like a phenomen
lines of code appeared instead of files i think
but i cant recall exactly
it just, i removed exec it worked normally, otherwise code appeared
..
dont mind as i cant recall or retry [new script somewhen soon]
On Mon, Mar 15, 2021 at 10:51 AM felix wrote:
> On Sat, Mar 13, 2021 at 01:05:32AM +0100, Alex fxmbsw7 Ratchev wrote:
> > i have no example to write here as this was past long
> Without sample, i'ts hard to represent your case!
>
> > the story was, i was coding a file server daemon, with socat,
> Wow!
>
> > and i figured to use exec why not more exact more efficient
>
> Something like:
>
> -- In any terminal (first)
> $ coproc socat TCP4-LISTEN: STDIO
> $ while read -u $COPROC foo;do echo $foo; echo $RANDOM
> >&${COPROC[1]};done
>
> -- In another terminal
> $ exec {netconn}<>/dev/tcp/localhost/
> $ echo >&$netconn foo ; read -u $netconn foo ; echo $foo
> 24522
> $ echo >&$netconn bar ; read -u $netconn foo ; echo $foo
> 29969
>
> (while you will see in first terminal:
> foo
> bar
> )
>
> > but using it resulted sometimes output of code of the script in the
> output
> > of the files
> > removing exec made it work normally as supposed
>
> Or are did you mean `EXEC` of `socat`?
>
> -- Don't run this if you don't understand what you do!
> socat TCP4-LISTEN: EXEC:/bin/bash
>
> ??
>
> --
> Félix
>
>
Re: Changing the way bash expands associative array subscripts
hello, excuse my bad english
your sample code that you write what it should produce you propose for the
future so ?
it doesnt make me much sense that unset -v assoc[$key] gives syntax error
or so..
also about the assoc_expand_once i dont understand
cant it be as written, expand_once ( maybe _at_beginning_only )
set unset -v assoc[$key] would expand key as alike the first argument of
[[ comparision
to a string $( echo foo ) .. no more further .. .. and work out .. .. ?
i dont understand im sorry
On Tue, Mar 16, 2021 at 7:03 AM Lawrence Velázquez wrote:
> > On Mar 15, 2021, at 9:03 PM, Léa Gris wrote:
> >
> > Please excuse my profanity of mentioning zsh in this list, but I really
> think features and behavior convergence can benefit end users in multiple
> ways, especially when expanding beyond the POSIX sh scope.
> >
> > What direction has taken zsh with expanding associative array indexes?
>
> Broadly speaking, zsh treats subscript expressions as if they are
> double-quoted, but it does not perform arithmetic expansion on associative
> array indices (although subscript expressions must still adhere to related
> parsing rules).
>
> % zsh --version; echo
> zsh 5.8 (x86_64-apple-darwin18.7.0)
>
> % cat /tmp/demo1
> # Chet's example modified to highlight certain behaviors
> foo() {
> echo uname >&2
> echo +1
> }
>
> declare -A assoc
> key='x$(foo)]=1,b[1$(foo)'
>
> assoc[$key]=0
> declare -p assoc b
>
> % zsh -f /tmp/demo1
> /tmp/demo1:declare:10: no such variable: b
> typeset -A assoc=( ['x$(foo)]=1,b[1$(foo)']=0 )
>
> However, it does perform multiple expansions in arithmetic contexts.
>
> % cat /tmp/demo2
> # Chet's example modified to highlight certain behaviors
> foo() {
> echo uname >&2
> echo +1
> }
>
> declare -A assoc
> key='x$(foo)]=1,b[1$(foo)'
>
> (( assoc[$key]++ ))
> declare -p assoc b
>
> % zsh -f /tmp/demo2
> uname
> uname
> typeset -A assoc=( [x+1]=1 )
> typeset -a b=( '' 1 )
>
> Furthermore, "as if they are double-quoted" is rather literal. (Special
> handling allows the use of a["foo"] instead of a[\"foo\"].)
>
> % cat /tmp/demo3
> declare -A a
> key='$(echo foo)'
> a[$key]=1
> a['$key']=2
> a["foo"]=3
>
> declare -p a
>
> % zsh -f /tmp/demo3
> typeset -A a=( ['"foo"']=3 ['$(echo foo)']=1 [\''$(echo foo)'\']=2
> )
>
> If we tweak the preamble to create the intended array (and disable NOMATCH
> to treat failed filename generation as bash does), the unset commands work
> the same as in Chet's proposal.
>
> % cat /tmp/demo4
> declare -A a
> key='$(echo foo)'
> a[$key]=1
> a[\$key]=2
> a[foo]=3
>
> # Avoid Chet's intentional error because it's difficult to get zsh
> to
> # imitate it faithfully.
> #unset -v a[$key]
> declare -p a
>
> # unsets element with key $key
> unset -v a['$key']
> declare -p a
>
> # unsets element with key $(echo foo)
> unset -v a["$key"]
> declare -p a
>
> # unsets element with key foo
> eval unset -v a\["$key"\]
> declare -p a
>
> % zsh -f +o NOMATCH /tmp/demo4
> typeset -A a=( ['$(echo foo)']=1 ['$key']=2 [foo]=3 )
> typeset -A a=( ['$(echo foo)']=1 [foo]=3 )
> typeset -A a=( [foo]=3 )
> typeset -A a=( )
>
> vq
>
is it a bug that PWD=whatever sets PS1's \w to that regardless
.. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == 2021-03-16+11:23:1920 ) #
Re: Changing the way bash expands associative array subscripts
no idea about your internal rules of keyword and builtin but clearly its gotta parse it at most 1. level otherwise its big security fault isnt it its a shell fuctionality keyword, unset, so .. On Tue, Mar 16, 2021 at 1:21 PM Greg Wooledge wrote: > On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote: > > it doesnt make me much sense that unset -v assoc[$key] gives syntax error > > or so.. > > Think of it this way: what would happen if you had a filename in a > variable -- say, $file -- and you ran this command: > > rm -f $file > > You'd expect that to fail, right? Of course. > > unset -v assoc[$key] fails for exactly the same reason. unset does not > have any magical powers. It's only a shell builtin, NOT a shell keyword. > Therefore, the standard shell rules apply. Expansions occur first, > followed by word splitting, which cause a list of argument words to be > created and passed as arguments to the builtin. > > key='two words' > unset -v assoc[$key] > > ==> 'unset' '-v' 'assoc[two' 'words]' > > You can even use set -x to see this in action: > > unicorn:~$ key='two words' > unicorn:~$ set -x > unicorn:~$ unset -v assoc[$key] > + unset -v 'assoc[two' 'words]' > bash: unset: `assoc[two': not a valid identifier > bash: unset: `words]': not a valid identifier > >
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
but is it a bug its a bug to use heavy subshells for such i understand the addment of this case tho On Tue, Mar 16, 2021 at 1:23 PM Chris Elvidge wrote: > On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == > > 2021-03-16+11:23:1920 ) # > > > > Yes, it seems \w (and \W) take their values from $PWD > If you want to register the current directory in $PS1 regardless, change > \w to `pwd` > > -- > Chris Elvidge > England > > >
Re: Changing the way bash expands associative array subscripts
i guess shell-keyword all then :)) On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote: > On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote: > > no idea about your internal rules of keyword and builtin > > unicorn:~$ type [ > [ is a shell builtin > unicorn:~$ type [[ > [[ is a shell keyword > > You know how you're allowed to omit quotes inside [[ but not inside [ ? > That's because [[ has magical powers. It's a "shell keyword". It has > its own special rules. > > > but clearly its > > gotta parse it at most 1. level otherwise its big security fault isnt it > > its a shell fuctionality keyword, unset, so .. > > I would not complain if unset became a shell keyword, and had a complete > revamp of its behavior. As long as we're willing to break backward > compatibility, which Chet seems like he's aiming to do anyway > >
Re: Changing the way bash expands associative array subscripts
as for shell keyword be more important and vital to shells, than more external [or so?] built ins unset -v var ## very internal to shell var extension thatss not possible to disable [[ .. ## a test for strings or so containing .. it would not make sense to have unset be lower than [[ On Tue, Mar 16, 2021 at 1:39 PM Alex fxmbsw7 Ratchev wrote: > i guess shell-keyword all then :)) > > On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote: > >> On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote: >> > no idea about your internal rules of keyword and builtin >> >> unicorn:~$ type [ >> [ is a shell builtin >> unicorn:~$ type [[ >> [[ is a shell keyword >> >> You know how you're allowed to omit quotes inside [[ but not inside [ ? >> That's because [[ has magical powers. It's a "shell keyword". It has >> its own special rules. >> >> > but clearly its >> > gotta parse it at most 1. level otherwise its big security fault isnt it >> > its a shell fuctionality keyword, unset, so .. >> >> I would not complain if unset became a shell keyword, and had a complete >> revamp of its behavior. As long as we're willing to break backward >> compatibility, which Chet seems like he's aiming to do anyway >> >>
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
okay, cool, thank you for valuable infos =)) On Tue, Mar 16, 2021 at 2:31 PM Chet Ramey wrote: > On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > No. If you want to set PWD instead of letting cd/pushd/popd manage it, > all bets are off. > > Just like setting HOME changes tilde expansion. > > > -- > ``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: Changing the way bash expands associative array subscripts
you write like when word splitting no use double quotes sure but as far as i understood: key='$( faulty_command )' unset -v assoc["$key"] would still get expanded i cant get friendly'ed to builtins being over keywords much more to say but i cant, greets tho On Wed, Mar 17, 2021 at 4:46 AM Robert Elz wrote: > Date:Tue, 16 Mar 2021 13:26:30 +0100 > From:Alex fxmbsw7 Ratchev > Message-ID: p09ca...@mail.gmail.com> > > | no idea about your internal rules of keyword and builtin but clearly > its > | gotta parse it at most 1. level otherwise its big security fault isnt > it > > No, it isn't. No more than > cd /; rm -fr * > is a "big security fault" (in the shell). Users who do > stupid things might be a big security fault, but it is not the > shell's job to stop that (if you think you need that help, > find some shell that still implements restricted mode, if there > are any (does bash?) and use that, then you'll be fairly well > protected - you also won't be able to do much). > > | its a shell fuctionality keyword, unset, so .. > > Lots of things are what seems to be shell functionality, that > changes nothing. If you don't want word splitting, add quotes. > Your responsibility. > > g...@wooledge.org said: > | I would not complain if unset became a shell keyword, and had a > complete > | revamp of its behavior. > > I would. keywords cannot be overridden by functions, and so should be > used only where absolutely required (which means, really, that in order to > work, they require a magic syntax, that the shell must implement). > And yes '[[' being a keyword, is, IMO, a mistake. unset requires > no more than regular shell parsing, and should be left alone. > > kre > > >
bug in auto completition, dunno if by completition package
i code on a bash feature linker 'ogt2' that binds functions, aliases, etc, by filenames and their content ( and location ( prepath \\ subpath ) ) now i have /root/ogt2/traps/ and being in /root/ogt2 i type traps i expected traps/ it autocompleted none more it shows 'traps' as only option to complete but it doesnt move on or add the slash i type trap i autocompletes to 'trap ' instead of also show traps/ peace
is it a bug that \e's dont get escaped in declare -p output
it makes the output no more possible if interpreted by tty the \e's get processed by terminal and no more .. just an example where it is so: var=$'1\e[G\e[K2' ; declare -p var if G was H for other line then it completly messes the terminal up isnt it better to escape by \e ? ..
Re: bug in auto completition, dunno if by completition package
and what about the traps to not-with-slash one ? bash: type: traps: not found On Wed, Mar 17, 2021 at 4:39 PM Chet Ramey wrote: > On 3/17/21 6:43 AM, Alex fxmbsw7 Ratchev wrote: > > i code on a bash feature linker 'ogt2' that binds functions, aliases, > etc, > > by filenames and their content ( and location ( prepath \\ subpath ) ) > > now i have /root/ogt2/traps/ and being in /root/ogt2 > > i type traps i expected traps/ it autocompleted none more it shows > > 'traps' as only option to complete but it doesnt move on or add the slash > > i type trap i autocompletes to 'trap ' instead of also show traps/ > > It completes because `trap' is a command name, and it appends the space > because that's the default on a successful completion. > > Command completion attempts its fallback directory completion only if there > are no command names that match. > > > -- > ``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 in auto completition, dunno if by completition package
when it works for you its no bug for me, ill try later that completition removation stuff but as upstream works it works, .. :) On Wed, Mar 17, 2021 at 7:06 PM Chet Ramey wrote: > On 3/17/21 12:45 PM, Alex fxmbsw7 Ratchev wrote: > > and what about the traps to not-with-slash one ? > > bash: type: traps: not found > > I get a slash appended when I try it. Maybe try it with a shell that > doesn't have bash-completion loaded, or remove all current completions > and try again. > > -- > ``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: is it a bug that \e's dont get escaped in declare -p output
hm at least now we know array declare -p formatting would work in workarounds, good to .. :) On Wed, Mar 17, 2021 at 9:05 PM Greg Wooledge wrote: > On Wed, Mar 17, 2021 at 09:58:24PM +0200, Ilkka Virta wrote: > > On Wed, Mar 17, 2021 at 8:26 PM Greg Wooledge wrote: > > > > > I thought, for a moment, that bash already used $'...' quoting for > > > newlines, but it turns out that's false. At least for declare -p. > > > It would be nice if it did, though. Newlines, carriage returns, escape > > > characters, etc. > > > > > > > It does in some cases: > > > > $ a=($'new \n line' $'and \e esc'); declare -p a > > declare -a a=([0]=$'new \n line' [1]=$'and \E esc') > > But not for string variables, it seems. > > unicorn:~$ unset a b; a=($'x\ny') b=$'c\nd'; declare -p a b > declare -a a=([0]=$'x\ny') > declare -- b="c > d" > > It would be nice if the string variables were handled the same way as > the array elements. > >
missing way to extract data out of data
there is way to crop data to wanted, by cropping the exclulsions away but what about a way to extract data, eg @( .. ) match not about using [[ =~ but only var internal stuff .. or do i miss there something
repost of alike 'missing a way to extract data'
as i got suggested here for help-bash for new .. there is ways to crop data to wanted by cropping the excludes out but where is the simple way of keeping matching i'd say implent backtrack references for @( .. ) etc groups pseudo exmaple declare -A big=( mess of data ) var=$( declare -p big ) now to extract the elements, beware with mess of data i dont mean 'mess' 'of' 'data' it needs to parse either no quotes, $' quotes or " quotes from beginning to end as greycat suggested, .. any idea ? im not looking for bad hacks or so actually more like adding demandant important stuff to bash's functionality such as regexes and back-references for groups .. no war make peace want war ? war the non peace
Re: repost of alike 'missing a way to extract data'
i have currently no example
i tried converting assoc 2 arr and reverses, as for examples, with content
being weird filenames
that tries were a week ago or so, i ended up in loops instead of parsing
declare -p output sadly
but i demand extraction stuff, not just cutting away ... isnt it obvious ..
i mean .. err .. ?
${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
and an extension for regex there
as for example, i can give you my garbage data
begin='declare -A a' end='declare -p a' per2 'a[$per]=' *
declare -A a=([""]="" ["] \$( eval echo shitt )"]="" [$'abc
\034[22]="bar"']="" [$'\034']="" [$'\n']="" [2]="" ["]"]="" [" a b"]=""
["' [b"]="" ["\" ["]="" [$'\' [1]=\034']="" ["];eval echo shitt"]=""
[$'foo\034 [2]="blah" ']="" [abc]="" ["abc [22]=\"bar\""]="" [blah]="" )
peace
On Thu, Mar 18, 2021 at 2:33 PM Greg Wooledge wrote:
> On Thu, Mar 18, 2021 at 02:15:19PM +0100, Alex fxmbsw7 Ratchev wrote:
> > pseudo exmaple
>
> Why not give a REAL example?
>
> > declare -A big=( mess of data )
> > var=$( declare -p big )
> >
> > now to extract the elements, beware with mess of data i dont mean 'mess'
> > 'of' 'data'
>
> You don't write bash code to parse bash syntax. You let bash do it
> for you.
>
> Apparently you are trying to serialize an associative array and transmit
> it from one instance of bash to another. That's totally fine, and
> declare -p is the right tool for that.
>
> In the second instance of bash, to reconstruct the serialized array,
> you simply eval the serialization (or source it, if it's in a file).
>
> In the first script:
>
> declare -A hash=(...)
> export serialized_hash="$(declare -p hash)"
> otherscript
>
> Then, inside otherscript:
>
> eval "$serialized_hash"
>
> Now you have an associative array named "hash", with a copy of the contents
> from the first script. If you want to "extract the elements", you simply
> use "${hash[key1]}" and so on.
>
>
Re: Changing the way bash expands associative array subscripts
wheres the sense of not having same var format rules as.. normal, but not for unset ? i can do arr[$key]= without problems, cool, why bug around big in unset ( aka choose keywords instead of lower for, ... important functionality ) On Wed, Mar 17, 2021 at 5:05 PM Jesse Hathaway wrote: > I would welcome this change, I struggled today with trying to > increment an associative array > in an arithmetic context. I think this change would make for much > better ergonomics when > working with associative arrays. Yours kindly, Jesse Hathaway > >
Re: repost of alike 'missing a way to extract data'
what, dude, of course you can regex eerything right
that is, for no quotes
till non escaped end, ] probably
for " its till nonescaped "
and for $' till nonescaped '
i can regex it or extglob it
hm ?
but i need the results of grouping of the matches ( '( .. )' )
On Thu, Mar 18, 2021 at 3:39 PM Greg Wooledge wrote:
> On Thu, Mar 18, 2021 at 02:44:06PM +0100, Alex fxmbsw7 Ratchev wrote:
> > isnt it obvious ..
>
> No.
>
> > ${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
> > and an extension for regex there
>
> That's a feature request. Chet can discuss that with you.
>
> All I can tell you is that this feature is not in any way suitable for
> retrieving an element from an associative array. If it actually existed,
> which of course it doesn't.
>
> > as for example, i can give you my garbage data
> >
> > begin='declare -A a' end='declare -p a' per2 'a[$per]=' *
> > declare -A a=([""]="" ["] \$( eval echo shitt )"]="" [$'abc
> > \034[22]="bar"']="" [$'\034']="" [$'\n']="" [2]="" ["]"]="" [" a b"]=""
> > ["' [b"]="" ["\" ["]="" [$'\' [1]=\034']="" ["];eval echo shitt"]=""
> > [$'foo\034 [2]="blah" ']="" [abc]="" ["abc [22]=\"bar\""]="" [blah]="" )
>
> I cannot make ANY sense of this. I don't know what you're doing or why.
>
> Whatever you're doing, it's ridiculously convoluted and obscure. There
> is probably some MUCH easier way to achieve the goal. If you would just
> tell us the goal, we might be able to help you do it.
>
>
Re: repost of alike 'missing a way to extract data'
as for goal, and no believance, it is handling quoting, string issues,
nothing else
you may know if you think about it im a freelance code there is nothing now
but major functionality issues
..
On Thu, Mar 18, 2021 at 3:57 PM Alex fxmbsw7 Ratchev
wrote:
> what, dude, of course you can regex eerything right
> that is, for no quotes
> till non escaped end, ] probably
> for " its till nonescaped "
> and for $' till nonescaped '
>
> i can regex it or extglob it
> hm ?
> but i need the results of grouping of the matches ( '( .. )' )
>
> On Thu, Mar 18, 2021 at 3:39 PM Greg Wooledge wrote:
>
>> On Thu, Mar 18, 2021 at 02:44:06PM +0100, Alex fxmbsw7 Ratchev wrote:
>> > isnt it obvious ..
>>
>> No.
>>
>> > ${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
>> > and an extension for regex there
>>
>> That's a feature request. Chet can discuss that with you.
>>
>> All I can tell you is that this feature is not in any way suitable for
>> retrieving an element from an associative array. If it actually existed,
>> which of course it doesn't.
>>
>> > as for example, i can give you my garbage data
>> >
>> > begin='declare -A a' end='declare -p a' per2 'a[$per]=' *
>> > declare -A a=([""]="" ["] \$( eval echo shitt )"]="" [$'abc
>> > \034[22]="bar"']="" [$'\034']="" [$'\n']="" [2]="" ["]"]="" [" a
>> b"]=""
>> > ["' [b"]="" ["\" ["]="" [$'\' [1]=\034']="" ["];eval echo shitt"]=""
>> > [$'foo\034 [2]="blah" ']="" [abc]="" ["abc [22]=\"bar\""]="" [blah]="" )
>>
>> I cannot make ANY sense of this. I don't know what you're doing or why.
>>
>> Whatever you're doing, it's ridiculously convoluted and obscure. There
>> is probably some MUCH easier way to achieve the goal. If you would just
>> tell us the goal, we might be able to help you do it.
>>
>>
Re: repost of alike 'missing a way to extract data'
i also wanna say
no extraction method is no good for a coding language ( no extraction as is
only minus ( substraction ) is possible but no .. )
why dont you just enable backreferences \ of match
for ${var/ and //
and impent a regex variant, as you do by [[ =~ anyway
On Thu, Mar 18, 2021 at 4:00 PM Alex fxmbsw7 Ratchev
wrote:
> as for goal, and no believance, it is handling quoting, string issues,
> nothing else
> you may know if you think about it im a freelance code there is nothing
> now but major functionality issues
> ..
>
> On Thu, Mar 18, 2021 at 3:57 PM Alex fxmbsw7 Ratchev
> wrote:
>
>> what, dude, of course you can regex eerything right
>> that is, for no quotes
>> till non escaped end, ] probably
>> for " its till nonescaped "
>> and for $' till nonescaped '
>>
>> i can regex it or extglob it
>> hm ?
>> but i need the results of grouping of the matches ( '( .. )' )
>>
>> On Thu, Mar 18, 2021 at 3:39 PM Greg Wooledge wrote:
>>
>>> On Thu, Mar 18, 2021 at 02:44:06PM +0100, Alex fxmbsw7 Ratchev wrote:
>>> > isnt it obvious ..
>>>
>>> No.
>>>
>>> > ${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
>>> > and an extension for regex there
>>>
>>> That's a feature request. Chet can discuss that with you.
>>>
>>> All I can tell you is that this feature is not in any way suitable for
>>> retrieving an element from an associative array. If it actually existed,
>>> which of course it doesn't.
>>>
>>> > as for example, i can give you my garbage data
>>> >
>>> > begin='declare -A a' end='declare -p a' per2 'a[$per]=' *
>>> > declare -A a=([""]="" ["] \$( eval echo shitt )"]="" [$'abc
>>> > \034[22]="bar"']="" [$'\034']="" [$'\n']="" [2]="" ["]"]="" [" a
>>> b"]=""
>>> > ["' [b"]="" ["\" ["]="" [$'\' [1]=\034']="" ["];eval echo shitt"]=""
>>> > [$'foo\034 [2]="blah" ']="" [abc]="" ["abc [22]=\"bar\""]="" [blah]=""
>>> )
>>>
>>> I cannot make ANY sense of this. I don't know what you're doing or why.
>>>
>>> Whatever you're doing, it's ridiculously convoluted and obscure. There
>>> is probably some MUCH easier way to achieve the goal. If you would just
>>> tell us the goal, we might be able to help you do it.
>>>
>>>
Re: repost of alike 'missing a way to extract data'
i tried as i said array stuff by declare -p
i tried to do the following thing without loop only with string assignments
but failed cause cutment is not so my thing, rather extractments
cat functions/assoc2arr
declare dest=$1 cont=( "${@:2}" ) i=-1 src key res
set --
while [[ -v cont[++i] ]] && src=${cont[i]} ; do
declare -n _src=$src
for key in "${!)src[@]}" ; do
res+=\ ${key@Q}
done
done
declare -ga "${dest:-arr}=\($res\)"
On Thu, Mar 18, 2021 at 4:03 PM Alex fxmbsw7 Ratchev
wrote:
> i also wanna say
> no extraction method is no good for a coding language ( no extraction as
> is only minus ( substraction ) is possible but no .. )
> why dont you just enable backreferences \ of match
> for ${var/ and //
> and impent a regex variant, as you do by [[ =~ anyway
>
> On Thu, Mar 18, 2021 at 4:00 PM Alex fxmbsw7 Ratchev
> wrote:
>
>> as for goal, and no believance, it is handling quoting, string issues,
>> nothing else
>> you may know if you think about it im a freelance code there is nothing
>> now but major functionality issues
>> ..
>>
>> On Thu, Mar 18, 2021 at 3:57 PM Alex fxmbsw7 Ratchev
>> wrote:
>>
>>> what, dude, of course you can regex eerything right
>>> that is, for no quotes
>>> till non escaped end, ] probably
>>> for " its till nonescaped "
>>> and for $' till nonescaped '
>>>
>>> i can regex it or extglob it
>>> hm ?
>>> but i need the results of grouping of the matches ( '( .. )' )
>>>
>>> On Thu, Mar 18, 2021 at 3:39 PM Greg Wooledge wrote:
>>>
>>>> On Thu, Mar 18, 2021 at 02:44:06PM +0100, Alex fxmbsw7 Ratchev wrote:
>>>> > isnt it obvious ..
>>>>
>>>> No.
>>>>
>>>> > ${var//@(abc|cde)@(bla|blubb)/\2\1} # just like sed
>>>> > and an extension for regex there
>>>>
>>>> That's a feature request. Chet can discuss that with you.
>>>>
>>>> All I can tell you is that this feature is not in any way suitable for
>>>> retrieving an element from an associative array. If it actually
>>>> existed,
>>>> which of course it doesn't.
>>>>
>>>> > as for example, i can give you my garbage data
>>>> >
>>>> > begin='declare -A a' end='declare -p a' per2 'a[$per]=' *
>>>> > declare -A a=([""]="" ["] \$( eval echo shitt )"]="" [$'abc
>>>> > \034[22]="bar"']="" [$'\034']="" [$'\n']="" [2]="" ["]"]="" [" a
>>>> b"]=""
>>>> > ["' [b"]="" ["\" ["]="" [$'\' [1]=\034']="" ["];eval echo shitt"]=""
>>>> > [$'foo\034 [2]="blah" ']="" [abc]="" ["abc [22]=\"bar\""]=""
>>>> [blah]="" )
>>>>
>>>> I cannot make ANY sense of this. I don't know what you're doing or why.
>>>>
>>>> Whatever you're doing, it's ridiculously convoluted and obscure. There
>>>> is probably some MUCH easier way to achieve the goal. If you would just
>>>> tell us the goal, we might be able to help you do it.
>>>>
>>>>
Re: repost of alike 'missing a way to extract data'
well i have nothing against, excepts my .c is weak
ill get the k&r book then we can talk about it
On Thu, Mar 18, 2021 at 4:27 PM Chet Ramey wrote:
> On 3/18/21 11:03 AM, Alex fxmbsw7 Ratchev wrote:
> > i also wanna say
> > no extraction method is no good for a coding language ( no extraction as
> is
> > only minus ( substraction ) is possible but no .. )
> > why dont you just enable backreferences \ of match
> > for ${var/ and //
> > and impent a regex variant, as you do by [[ =~ anyway
>
> "Why don't you," indeed.
>
> --
> ``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/
>
in devel tree currently control-l doesnt refresh it prints newline or something non clearing
i just report, sorry for overheat
about control-l
its a fresh system i probably dont have readline-dev or such maybe its cause that
Re: in devel tree currently control-l doesnt refresh it prints newline or something non clearing
hm how can i help its a fresh deb all-tree's system, i had bash 5.1.4-maint from a month or so ago ( only binary from another system ) and fetched the new today and compiled and installed, and cp'd to /bin i suspect it could be internal readline short bindings issue, instdead of having the -dev installed how can i help fixing or analyzing this ? On Thu, Mar 18, 2021 at 8:24 PM Chet Ramey wrote: > On 3/18/21 12:08 PM, Alex fxmbsw7 Ratchev wrote: > > i just report, sorry for overheat > > I can't reproduce 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/ >
Re: about control-l
do you error out on configure for this case or not cause mine was running fine On Thu, Mar 18, 2021 at 8:25 PM Chet Ramey wrote: > On 3/18/21 12:10 PM, Alex fxmbsw7 Ratchev wrote: > > its a fresh system i probably dont have readline-dev or such maybe its > > cause that > > You need at least ncurses-devel (or ncurses) so bash configure can find > the terminfo library it needs to look up terminal control character > sequences, and bash can link with it. > > > -- > ``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: about control-l
it may also be config path error cause i didnt PREFIX or so cause i dont want to but cp'd to /bin , but then still it installed and found paths i dunno, but i wish to analyze the problem, just help me on it, .. show me some cmds or what i should try, .. On Thu, Mar 18, 2021 at 8:29 PM Alex fxmbsw7 Ratchev wrote: > do you error out on configure for this case or not > cause mine was running fine > > On Thu, Mar 18, 2021 at 8:25 PM Chet Ramey wrote: > >> On 3/18/21 12:10 PM, Alex fxmbsw7 Ratchev wrote: >> > its a fresh system i probably dont have readline-dev or such maybe its >> > cause that >> >> You need at least ncurses-devel (or ncurses) so bash configure can find >> the terminfo library it needs to look up terminal control character >> sequences, and bash can link with it. >> >> >> -- >> ``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: missing way to extract data out of data
yea well it does wonders, however was looking for a way without spawning externals like gawk.. maybe in future there will be =) On Fri, Mar 19, 2021 at 2:02 AM Dale R. Worley wrote: > Alex fxmbsw7 Ratchev writes: > > there is way to crop data to wanted, by cropping the exclulsions away > > but what about a way to extract data, eg @( .. ) match > > not about using [[ =~ but only var internal stuff > > .. or do i miss there something > > If you want to do a pattern-match against a string, then extract a part > of it, a common way is to use sed. For instance, to extract a word and > remove spaces before and after it: > > $ STRING=' abc def ' > $ WORD="$( <<<$STRING sed -e 's/^ *\([^ ]*\) *$/\1/' )" > $ echo "$WORD" > > It is common to use common Unix utilities to modify data items within > shell scripts. > > Dale >
why does this define bla() instead of respect the newline as command separator
eval $'alias n=bla\nn() { type $FUNCNAME ; }\nn'
bla is a function
bla ()
{
type $FUNCNAME
}
it was supposed to be n() ..
Re: missing way to extract data out of data
ehe :)) you tell me rather a good pike beginnings resource On Fri, Mar 19, 2021 at 9:42 AM Andreas Schwab wrote: > On Mär 19 2021, Alex fxmbsw7 Ratchev wrote: > > > yea well it does wonders, however was looking for a way without spawning > > externals like gawk.. maybe in future there will be =) > > You know where to get perl or python. > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
Re: why does this define bla() instead of respect the newline as command separator
oh i know, it works as expected by alias definition, there is no space
between alias defined and op, so it gets expanded correspondingly
thank you
On Fri, Mar 19, 2021, 10:14 Mike Jonkmans wrote:
> On Fri, Mar 19, 2021 at 09:12:34AM +0100, Alex fxmbsw7 Ratchev wrote:
> > eval $'alias n=bla\nn() { type $FUNCNAME ; }\nn'
> > bla is a function
> > bla ()
> > {
> > type $FUNCNAME
> > }
> >
> > it was supposed to be n() ..
>
> The eval $'...' can be left out.
>
>
> $ echo $BASH_VERSION
> 5.0.17(1)-release
> $ alias n=bla
> $ n() { type $FUNCNAME; }
> $ declare -pf n
> bash: declare: n: not found
> $ declare -pf bla
> bla ()
> {
> type $FUNCNAME
> }
>
> It is the same on 5.1.4(1)-release.
>
> I would have expected that n was a defined function.
> But I would not have bet on it.
>
> Regards, Mike Jonkmans
>
>
Re: why does this define bla() instead of respect the newline as command separator
yes, thank you
On Fri, Mar 19, 2021, 14:11 Chet Ramey wrote:
> On 3/19/21 4:12 AM, Alex fxmbsw7 Ratchev wrote:
> > eval $'alias n=bla\nn() { type $FUNCNAME ; }\nn'
> > bla is a function
> > bla ()
> > {
> > type $FUNCNAME
> > }
> >
> > it was supposed to be n() ..
>
> `n' is the first word in a position where a simple command can be parsed,
> so it's subject to alias expansion.
>
>
> --
> ``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: why does this define bla() instead of respect the newline as command separator
try with dev bash version, aliases work there, also include an ending space
in your aliases to make the next get expanded instead of passed as arg
On Fri, Mar 19, 2021, 15:59 Oğuz wrote:
> On Fri, Mar 19, 2021 at 4:11 PM Chet Ramey wrote:
>
>> On 3/19/21 4:12 AM, Alex fxmbsw7 Ratchev wrote:
>> > eval $'alias n=bla\nn() { type $FUNCNAME ; }\nn'
>> > bla is a function
>> > bla ()
>> > {
>> > type $FUNCNAME
>> > }
>> >
>> > it was supposed to be n() ..
>>
>> `n' is the first word in a position where a simple command can be parsed,
>> so it's subject to alias expansion.
>>
>
> Not much related, but isn't this supposed to work?
>
> $ cat foo.sh
> alias c='case ' w='foo ' i='in ' p=') ' e='esac' u='uname ' s='; '
> c w i e
> c w i w p e
> c w i w p u s e
> $
> $ for sh in ash 'bash -O expand_aliases' bosh dash gwsh ksh mksh oksh yash
> zsh; do echo $sh; $sh ash
> Linux
> bash -O expand_aliases
> bash: line 2: syntax error near unexpected token `newline'
> bash: line 2: `c w i e'
> bosh
> Linux
> dash
> Linux
> gwsh
> Linux
> ksh
> ksh: syntax error at line 2: `i' unexpected
> mksh
> Linux
> oksh
> Linux
> yash
> Linux
> zsh
> zsh: parse error near `i'
> zsh: parse error near `i'
> zsh: parse error near `i'
>
>
>>
>>
>> --
>> ``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: in devel tree currently control-l doesnt refresh it prints newline or something non clearing
thank you i dunno about gdb but adding ncurses et la fixed it thanks On Fri, Mar 19, 2021 at 2:18 PM Chet Ramey wrote: > > On 3/18/21 3:28 PM, Alex fxmbsw7 Ratchev wrote: > > hm how can i help > > its a fresh deb all-tree's system, i had bash 5.1.4-maint from a month or > > so ago ( only binary from another system ) and fetched the new today and > > compiled and installed, and cp'd to /bin > > i suspect it could be internal readline short bindings issue, instdead of > > having the -dev installed > > > > how can i help fixing or analyzing this ? > > If you want to debug it, and you're sure that you've linked bash against a > working ncurses library (use ldd to check), use gdb and see what's > happening. > > Set a breakpoint in rl_clear_screen, run bash, type ^L, and when the > breakpoint hits, look at the value of _rl_term_clrpag. That is the > control sequence readline got from terminfo to clear the screen. Make > sure it's what your terminal expects to use to clear the screen. > > -- > ``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/
is there no copy of vars declared for every function but one global 'local' only ?
i have my codes much ready, but now on a clean reboot i noticed it doesnt do few stuffs anymore i call a per code that does eval, which i seem to call twice or trice inside stacked the content of args=( ) or files=( ) doesnt seem anymore active after some run could that be ? i guess the solution is to make a for copy instead of [[ -v args[++i] but with that how to make it extend-able for anyone who cares about the code, attached is ogt.tgz in the code ( ogt/ogt ) there is . "$_hd"/function/per '. "$_hd"/init/"$per"' \ set_n_shopt mktermv vars aliases functions keywords traps paths autoloads till vars it works, or halfways, then aliases and the rest dont get parsed at all cause args[++i] or files[++i] is no more ogt.tgz Description: application/compressed-tar
about the local not-on-every-function-separately var issue
i realize its somewhat of a big limitation, to have only global and
one level further ( local ) args, no per function
however about my code, i fixed it with a growing mapfile reader
'mapfile -t -d "" -O ${#big[@]} big <"$_hd"/init/"$per"' \
or at least partly fixed, yet stuff worked
and eval that in the end
i think the for loop didnt change anything as that wasnt a copy-var also
i wonder what a solultion to this would be
Re: about the local not-on-every-function-separately var issue
im sorry to not be able to reply to all your stuffs
you didnt make it easy
im happy it works for me now
On Mon, Mar 22, 2021 at 3:43 AM Greg Wooledge wrote:
>
> On Mon, Mar 22, 2021 at 03:12:25AM +0100, Alex fxmbsw7 Ratchev wrote:
> > i realize its somewhat of a big limitation, to have only global and
> > one level further ( local ) args, no per function
>
> One or more of your assumptions are wrong.
>
> Bash uses "dynamic scope" when it expands variables. This means that
> it looks first in the current functions local variables; if the variable
> isn't found there, it looks in the caller's local variables, and then
> in the caller's caller's local variables, and so on, until it reaches
> the global scope.
>
>
> f() {
> local var=set_in_f
> g
> }
>
> g() {
> echo "var is $var"
> }
>
> var=global
> f
> # Prints "var is set_in_f"
>
>
> Now, the big question is WHY you thought something which is not correct.
>
> The most common reasons that people think something which is wrong are:
>
> 1) They heard or read it somewhere, and did not verify it themselves.
>
> 2) They encountered a problem with their own program, and while attempting
>to track down the problem, they took a wrong turn, and did not fully
>diagnose the situation. They drew a wrong conclusion from partial data.
>
> In your case, I suspect it's #2.
>
> This project that you've been working on is so incredibly arcane,
> convoluted and bizarre that *nobody* understands it, including you. Who
> knows how many other fallacious assumptions are baked into it, since you
> are apparently incapable of simplifying anything down to the most basic
> level for debugging, or even explaining what your *goal* is.
>
Re: why does this define bla() instead of respect the newline as command separator
case statements are imho string comparision, nothing to do with aliases On Mon, Mar 29, 2021, 17:23 Chet Ramey wrote: > On 3/19/21 10:59 AM, Oğuz wrote: > > > Not much related, but isn't this supposed to work? > > > > $ cat foo.sh > > alias c='case ' w='foo ' i='in ' p=') ' e='esac' u='uname ' s='; ' > > c w i e > > Bash is pretty careful not to perform alias expansion in case statement > pattern lists, even to the point where that overrides the 'alias expand > the next word because the previous expansion ended with a space' > semantics. > > I could flip that, I suppose, even if the `use case' is this hypothetical > example. > > -- > ``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: Changing the way bash expands associative array subscripts
i still vote for same syntax to unset as setting it, makes only sense On Wed, Mar 31, 2021, 01:05 konsolebox wrote: > On Tue, Mar 16, 2021 at 8:12 AM Chet Ramey wrote: > > This means that, given the following script, > > > > declare -A a > > key='$(echo foo)' > > a[$key]=1 > > a['$key']=2 > > a["foo"]=3 > > > > # never worked > > unset -v a[$key] > > declare -p a > > > > # unsets element with key $key > > unset -v a['$key'] > > declare -p a > > > > # unsets element with key $(echo foo) > > unset -v a["$key"] > > declare -p a > > > > # unsets element with key foo > > eval unset -v a\["$key"\] > > declare -p a > > > > you'll get this output: > > > > example: line 8: unset: `a[$(echo': not a valid identifier > > example: line 8: unset: `foo)]': not a valid identifier > > declare -A a=(["\$(echo foo)"]="1" ["\$key"]="2" [foo]="3" ) > > declare -A a=(["\$(echo foo)"]="1" [foo]="3" ) > > declare -A a=([foo]="3" ) > > declare -A a=() > > As I've observed, in single expansion mode, unset will fail to unset a > value when the key has a closing bracket in it. Perhaps unset should > check the last character first when looking for the closing bracket. > Tested in 5.1.4. > > -- > konsolebox > >
Re: Empty array referenced by indirection reports unbound variable
arr=( ) implies no [0]=
On Mon, Apr 5, 2021, 22:46 konsolebox wrote:
> set -u
> array=()
> __ref=array[@]
> : "${array[@]}" # Reports nothing
> : "${!__ref}" # Unbound variable
>
> Using bash version 5.1.4. I know this can be avoided by using namerefs
> instead but indirection is more portable when no assignment is needed
> and this sometimes allows my portable functions to have less versions.
>
> The detection of unbound variables seem to have become more reasonable
> since 5.0 and I hope it gets improved further. I don't use set -u in
> older bash and it's only for development mode.
>
> --
> konsolebox
>
>
Re: Empty array referenced by indirection reports unbound variable
what i meant was there is not one element defined so .. any reference to anything in it will be not set.. makes sense @ is not defined i remember !var worked with it, or at least other defined sub elements On Tue, Apr 6, 2021, 16:26 konsolebox wrote: > On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7 Ratchev > wrote: > > > > arr=( ) implies no [0]= > > Also `arr=()` does not imply `arr[0]=`. `arr[0]` remains unset and not > assigned to any. Not even an empty string. > > -- > konsolebox >
Re: Empty array referenced by indirection reports unbound variable
im sorry i dont support set -u cant discuss it On Tue, Apr 6, 2021, 16:40 konsolebox wrote: > On Tue, Apr 6, 2021 at 10:38 PM Alex fxmbsw7 Ratchev > wrote: > > > > what i meant was there is not one element defined so .. any reference to > anything in it will be not set.. makes sense @ is not defined > > i remember !var worked with it, or at least other defined sub elements > > @ means everything or nothing. Unbound variable errors should not apply to > it. > > -- > konsolebox >
Re: Empty array referenced by indirection reports unbound variable
set sets args, and exits null
no bug there
On Wed, Apr 7, 2021, 16:40 konsolebox wrote:
> On Wed, Apr 7, 2021 at 9:25 PM Chet Ramey wrote:
> >
> > On 4/5/21 4:45 PM, konsolebox wrote:
> > > set -u
> > > array=()
> > > __ref=array[@]
> > > : "${array[@]}" # Reports nothing
> >
> > This is a special case, mirroring the special case that POSIX carved out
> > for $@ and $* in 2009.
> >
> > > : "${!__ref}" # Unbound variable
> >
> > But this is not. Bash looks for __ref, finds it with a value of array[@],
> > and attempts to expand that. It expands to null (internally), since there
> > are no array elements, which becomes the value of the parameter
> expansion.
> >
> > Since the expansion (${!__ref}) resulted in the null string, `set -u'
> kicks
> > in and bash reports a fatal error.
>
> But that doesn't seem consistent since `set -- "${!__ref}"; echo "$#"`
> shows 0, meaning it didn't expand to a null string but practically
> nothing. Does that mean internally ${!__ref} expands to null string
> but checks for a flag if it's an array expansion before the actual
> resulting expansion? If that's the case shouldn't it be the same when
> reporting unbound variable?
>
>
> --
> konsolebox
>
>
Re: bug report
you wrong set set -e shopt -s extglob da=( ?(a)match ) declare -p da i recomment u dont set -e On Fri, Apr 23, 2021, 16:43 john wrote: > From: john > To: bug-bash@gnu.org > Subject: ls dumps bash > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' > -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/b > ash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' > -DNON_INTERACTIVE_LOGIN_SHELLS > uname output: Linux john-arch 5.11.16-arch1-1 #1 SMP PREEMPT Wed, 21 Apr > 2021 17:22:13 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 4 > Release Status: release > > Description: > After the two commands as specified, the bash session ends > unexpectedly > > Repeat-By: > set -e extglob > ls ?(0)9,v > > >
tab compl doesnt complete ./some'thing filename at all
mkdir ttt ; cd ttt printf 'printf success' >some\'thing chmod +x * ./tabtab == nothing found by samus aran on freenode irc
