Cursor stuck/frozen, only backspace unfreezes
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: solaris2.9 Compiler: /opt/studio/SOS12/SUNWspro/bin/cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='solaris2.9' -DCONF_MACHTYPE='i386-pc-solaris2.9' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/csw/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DSOLARIS -I. -I. -I./include -I./lib -I/opt/csw/include -xO3 -m32 -xarch=386 -xnorunpath uname output: SunOS ray3 5.10 Generic_141445-09 i86pc i386 i86pc Machine Type: i386-pc-solaris2.9 Bash Version: 4.1 Patch Level: 5 Release Status: release Description: I am using bash 4.1.5 on Solaris 10 x86 (binary from opencsw.org built on Solaris 9) in an xterm 243. Every now and then the text cursor "freezes", i.e. subsequent keyboard input doesn't show up. truss'ing the bash process shows that it's still reading the keys, but it doesn't process/display them. $ truss -p 26716 read(0, 0x08047534, 1) (sleeping...) read(0, " a", 1)= 1 read(0, " s", 1)= 1 read(0, " d", 1)= 1 read(0, " f", 1)= 1 read(0, " ", 1)= 1 read(0, " ", 1)= 1 read(0, " ", 1)= 1 read(0, 0x08047534, 1) (sleeping...) read(0, " 1", 1)= 1 read(0, " 2", 1)= 1 read(0, " 3", 1)= 1 read(0, " 4", 1)= 1 read(0, 0x08047534, 1) (sleeping...) Hitting backspace twice "unfreezes" the cursor and everything is back to normal. Previously entered characters don't show up, but new ones do. ... read(0, "\b", 1)= 1 read(0, "\b", 1)= 1 write(2, "\b1B [ K", 4) = 4 read(0, 0x08047534, 1) (sleeping...) read(0, " ", 1)= 1 write(2, " ", 1) = 1 read(0, " ", 1)= 1 ... The binary hasn't been built with debugging symbols. When the issue occurs, the stack trace looks like below. Any idea what could be wrong here? Please let me know if you need any further information. $ pstack core.26716 core 'core.26716' of 26716: -bash fee09ff7 read (0, 8047534, 1) 080b8c21 rl_getc (80f6dd8) + 1f 080b8be7 rl_read_key (0, 804755c, 80aba46, 8047564, 80aba60, 8047570) + ad 080ab914 readline_internal_char (8047564, 80aba60, 8047570, 80ab6fe, 808b5d6, 8047580) + 5c 080aba46 (8047570, 80ab6fe, 808b5d6, 8047580, 8067595, 8113e08) 080aba60 (808b5d6, 8047580, 8067595, 8113e08, 8047770, 8047588) 080ab6fe readline (8113e08) + 37 08067595 (804759c, 8067d13, 0, 80475e0, 8047770, 80475b0) 0806750d (0, 80475e0, 8047770, 80475b0, 806869c, 1) 08067d13 (1) 0806869c (0) 0806825d (0, 0, 0, 80feea8, 0, 8102000) 08065e05 yyparse (0, 8047de8, 8065c7c, 0, 0, 0) + 12f 08065bd9 parse_command (0, 0, 0, 0, 8047dfc, 80659f9) + 56 08065c7c read_command (0, 0, 1, 8047e1c, 8064010, 8047e84) + 8c 080659f9 reader_loop (8047e84, 8047e04, feffb818, 1, 0, 1) + dd 08064010 main (1, 8047e48, 8047e50) + 638 08063942 (1, 8047eec, 0, 8047ef2, 8047eff, 8047f0f) Repeat-By: Didn't yet identify how this issue can be triggered.
Re: bash built-ins `true' and `false' undocumented
I am writing to follow up on this old bug report about the lack of documentation for the bash built-ins 'true' and 'false'. I agree with the previous arguments on why these built-ins should be documented in 'info bash', and I would like to add two more reasons: - The commands 'true' and 'false' that are documented in 'info coreutils' are different from the bash built-ins with the same names, so documenting them in 'info bash' wouldn't count as duplication. - The built-ins 'true' and 'false' are the only ones that are missing from ‘info bash’, which makes them inaccessible to the commands 'info bash true' and 'info bash false'. Thanks for your attention.
The bash built-ins 'true' and 'false' are undocumented in info and man page.
I guess there is not too much to say about the bash built-ins 'true' and 'false'. Nonetheless, I suggest that the info pages should list these built-ins individually like other built-ins. Currently, the only hint on their existence in the info or man page is in the node (or man page section) called "Shell Builtin Commands" saying that: The `:', `true', `false', and `test' builtins do not accept options and do not treat `--' specially. I am aware that these builtins are documented in 'help true', 'help false', 'info coreutils true' and 'info coreutils false', but I suggest documenting them in the info and man pages too for the following reasons: - 'info bash' begins with "This text is a brief description of the features that are present in the Bash shell", it also says "This manual is meant as a brief introduction to features found in Bash. The Bash manual page should be used as the definitive reference on shell behavior.", which would suggest that "man" or "info" (or both) should document these builtins. - The commands 'true' and 'false' that are documented in 'info coreutils' are different from the bash built-ins with the same names, so documenting them in 'info bash' wouldn't count as duplication. - The built-ins 'true' and 'false' are the only ones that are missing from the ‘info bash’ index, which makes them inaccessible to the commands 'info bash true' and 'info bash false'. Thanks for your attention. Bash version: 5.2.11
maybe a bug in bash?
Hello,
I'm sending this mail a past minutes ago, but I was not a member of this
mailing list. The mail was not listed in the archive, so I send it
again, with membership of the mailing list. I hope I don't sending it
twice to you.
I'm not sure, if I found a bug or if I miss some understanding, but I
want to report it, if it is a bug. Please tell me more, if I'm right or
if it is my mistake.
I have a script, in which I have an password (I get it from a password
manager - no excitement ;D ). The password begin with a $ and have an &
in middle. I want to use this password in an here document, which inject
some commands into a SSH-Connection (for simplification, I use the bash
instead of ssh in the test script below). To use the password in the
here document, I need to escape the special character. For this, I use
printf. The echo command in the here document give me the right output.
But if I run a subshell in the here document, the first \ for the $ is
being cut away. But why? At the moment I think this is a bug. But if it
is no bug, can you tell me why bash do this? My bash version is:
5.1.16(1)-release (x86_64-pc-linux-gnu) via Ubuntu 22.04.2 LTS.
You find a test script here:
#!/usr/bin/env bash
initial_password="\$abc&xyz"
echo "initial password: " $initial_password
printf -v password '%q' $initial_password
echo "initial password with escaped characters: " $password
bash << EOF
echo "password in here document: " ${password@Q}
/bin/bash -c "echo 'password in subshell in here document: ' ${password@Q}"
EOF
The output:
initial password: $abc&xyz
initial password with escaped characters: \$abc\&xyz
password in here document: \$abc\&xyz
password in subshell in here document: $abc\&xyz
Thank you very much!
Mit freundlichen Grüßen Sebastian Luhnburg IT
--
swp software systems GmbH & Co. KG Königsbrücker Straße 124 01099
Dresden Tel: 0351-492850 Fax: 0351-4928550 www: https://www.vi-bim.de
Kennen Sie schon unsere FAQ-Wissensdatenbank? Einfach hier klicken:
https://faq.vi-bim.de Unsere Datenschutzerklärung finden Sie unter
https://datenschutz.vi-bim.de Registergericht: Amtsgericht Dresden HRA
3008 persönlich haftender Gesellschafter: swp Beteiligungs GmbH
Registergericht: Amtsgericht Dresden HRB 15 20 9 Geschäftsführer: Holger
Schönemann, Stefan Urlberger
OpenPGP_0x1E7D455B730DAD17.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
maybe a bug in bash?
Hello,
I'm not sure, if I found a bug or if I miss some understanding, but I
want to report it, if it is a bug. Please tell me more, if I'm right or
if it is my mistake.
I have a script, in which I have an password (I get it from a password
manager - no excitement ;D ). The password begin with a $ and have an &
in middle. I want to use this password in an here document, which inject
some commands into a SSH-Connection (for simplification, I use the bash
instead of ssh in the test script below). To use the password in the
here document, I need to escape the special character. For this, I use
printf. The echo command in the here document give me the right output.
But if I run a subshell in the here document, the first \ for the $ is
being cut away. But why? At the moment I think this is a bug. But if it
is no bug, can you tell me why bash do this?
You find a test script here:
#!/usr/bin/env bash
initial_password="\$abc&xyz"
echo "initial password: " $initial_password
printf -v password '%q' $initial_password
echo "initial password with escaped characters: " $password
bash << EOF
echo "password in here document: " ${password@Q}
/bin/bash -c "echo 'password in subshell in here document: ' ${password@Q}"
EOF
The output:
initial password: $abc&xyz
initial password with escaped characters: \$abc\&xyz
password in here document: \$abc\&xyz
password in subshell in here document: $abc\&xyz
Thank you very much!
Mit freundlichen Grüßen Sebastian Luhnburg IT
--
swp software systems GmbH & Co. KG Königsbrücker Straße 124 01099
Dresden Tel: 0351-492850 Fax: 0351-4928550 www: https://www.vi-bim.de
Kennen Sie schon unsere FAQ-Wissensdatenbank? Einfach hier klicken:
https://faq.vi-bim.de Unsere Datenschutzerklärung finden Sie unter
https://datenschutz.vi-bim.de Registergericht: Amtsgericht Dresden HRA
3008 persönlich haftender Gesellschafter: swp Beteiligungs GmbH
Registergericht: Amtsgericht Dresden HRB 15 20 9 Geschäftsführer: Holger
Schönemann, Stefan Urlberger
OpenPGP_0x1E7D455B730DAD17.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Docs: Duplicated explanation of "quote removal" on manual
Hello, The manual seems to repeat the same information two paragraphs apart: On Section 3.5 Shell Expansions, a paragraph reads: > After these expansions are performed, quote characters present in the original word are removed unless they have been quoted themselves (quote removal). Then, after only one paragraph, another paragraph reads: > After all expansions, quote removal (see Quote Removal) is performed. I suggest removing the second one and moving the cross-reference to the first one. Thanks for your time.
Re: maybe a bug in bash?
Thank you very much for your quick answer!
I am not sure what do you mean with "open the quote"? I try to copy your
example, but my copy did not work. I wrote this:
#!/usr/bin/env bash
initial_password='$abc&xyz'
echo "initial password: " $initial_password
among_password="${initial_password@Q}"
echo "among password: " $among_password
password="${among_password@Q}"
echo "end password: " $password
bash << EOF
echo "password in here document: " ${password@Q}
/bin/bash -c "echo 'password in subshell in here document: ' ${password@Q}"
EOF
But I got this:
initial password: $abc&xyz
among password: '$abc&xyz'
end password: ''\''$abc&xyz'\''' # single quotes!
password in here document: ''\''$abc&xyz'\'''
password in subshell in here document: ''\''&xyz'\'''
p.s.: in the final script, it is only one SSH:
ssh user@machine << EOF
/bin/bash -c "do something with the password"
EOF
Mit freundlichen Grüßen
Sebastian Luhnburg
IT
--
swp software systems GmbH & Co. KG
Königsbrücker Straße 124
01099 Dresden
Tel: 0351-492850
Fax: 0351-4928550
www:https://www.vi-bim.de
Kennen Sie schon unsere FAQ-Wissensdatenbank? Einfach hier
klicken:https://faq.vi-bim.de
Unsere Datenschutzerklärung finden Sie unterhttps://datenschutz.vi-bim.de
Registergericht: Amtsgericht Dresden HRA 3008
persönlich haftender Gesellschafter:
swp Beteiligungs GmbH
Registergericht: Amtsgericht Dresden HRB 15 20 9
Geschäftsführer: Holger Schönemann, Stefan Urlberger
Am 29.06.23 um 13:00 schrieb Dominique Martinet:
Sebastian Luhnburg wrote on Thu, Jun 29, 2023 at 11:55:12AM +0200:
initial_password="\$abc&xyz"
echo "initial password: " $initial_password
printf -v password '%q' $initial_password
echo "initial password with escaped characters: " $password
bash << EOF
echo "password in here document: " ${password@Q}
/bin/bash -c "echo 'password in subshell in here document: ' ${password@Q}"
password here is \$abc\&xyz, and the @Q escape just makes
${password@Q} '\$abc\&xyz' (adds single quotes).
What running it in a subshell (ssh, or sh/bash -c) changes here is the
order in which things are unescaped.
Note the here-doc substitutes ${password@Q}, so this is the same as
running a file with the content:
```
echo "password in here document: " '\$abc\&xyz'
/bin/bash -c "echo 'password in subshell in here document: ' '\$abc\&xyz'"
```
Like this, you can see that in the former case, the echo command gets
the password in single quotes, while the subshell's echo is first
interpreted in double-quotess.
In double-quotes, \$ is simplified to $ (as the lack of backslash would
just get you the variable)
Note that since the here-doc first expands the variable, you cannot
solve this by using single quotes: the variable would just end the
quoting!
... At which point all you need to do is just to open the quote,
e.g. the following:
a='$foo&bar'
b="${a@Q}"
c="${b@Q}"
ssh localhost <
OpenPGP_0x1E7D455B730DAD17.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: maybe a bug in bash?
Hello Greg,
thank you for your quick answer, too!
First, I am not a Bash mastermind or have deeper knowledge about secure
programming. Your suggestion about the risk of coding injection is very
interesting! But I will read the full text after my holidays, which will
begin after this E-Mail :)
But I will explain what I want to do and why I think it is a good way
(it may be a little bit off topic for this mailing list).
First, in my LPIC-1 course the lecturer tell me it is better (not
binding) to deny SSH login for root users (especially for the user with
the name root). The reason is simple: decrease the attack surface. Yes,
a secure password needs a lot of time to be cracked via brute force, but
if the attacker did not know the username, which is needed to login, the
attacker must get two things. For my opinion, the decrease the attack
surface is a good approach.
Why I did not use SSH keys instead of SSH password login? We use a
self-hosted password manager (precise Bitwarden). So, we have a central
collection point of credentials and sensitive data. Every server have a
unique password. If I use SSH keys, it is a decentral approach. Every
user must manage his keys, which allows to connect to the servers. E.g.
if the user change his computer, the WSL instance etc pp, all keys must
secure separately from decentralized places. Yes, an SSH jump host could
be a solution, but this is a future project. At the moment, I think the
use of a password manager is an easier way to do this.
You suggest to use an argument, to pass the password. Please correct me
if I be wrong, but to write one or more password(s) in clear text as an
argument in the terminal (./myscript.sh password1 password2) is not the
best practice (the Bash history save the last x commands). To get the
input via an password manager (like Bitwarden CLI) is at this point the
better way I think (code injection stay be a problem, if I use the
passwords in an awkward way in my script).
Mit freundlichen Grüßen
Sebastian Luhnburg
IT
--
swp software systems GmbH & Co. KG
Königsbrücker Straße 124
01099 Dresden
Tel: 0351-492850
Fax: 0351-4928550
www:https://www.vi-bim.de
Kennen Sie schon unsere FAQ-Wissensdatenbank? Einfach hier
klicken:https://faq.vi-bim.de
Unsere Datenschutzerklärung finden Sie unterhttps://datenschutz.vi-bim.de
Registergericht: Amtsgericht Dresden HRA 3008
persönlich haftender Gesellschafter:
swp Beteiligungs GmbH
Registergericht: Amtsgericht Dresden HRB 15 20 9
Geschäftsführer: Holger Schönemann, Stefan Urlberger
Am 29.06.23 um 15:42 schrieb Greg Wooledge:
On Thu, Jun 29, 2023 at 11:33:15AM +0200, Sebastian Luhnburg wrote:
I want to use this password in an here document, which inject some
commands into a SSH-Connection (for simplification, I use the bash instead
of ssh in the test script below).
Skipping the "is it a bug or not" part, which has already been addressed
as a mis-quoting issue, let's talk about the goal.
First of all, is this the password *of* the ssh connection itself? If
so, that can be addressed by switching to key-based authentication (and
either using a key with no passphrase on it, or an ssh-agent to hold
your passphrase).
Second, are you trying to do something like this:
sshnonr...@some.host 'sudo some command'
where the password is for "sudo" because you aren't logging in directly
as root? The answer to this is so blastedly obvious that I shouldn't
have to state it, but nonetheless, here we are: just ssh in as root
instead of nonroot + sudo.
Some folks will scream that this is a bad idea, horrible practice, can't
do it, etc. These folks are idiots. Ssh can be configured to allow
root logins only when using key authentication. That's as secure as you
could ask for. Certainly it's at *least* as secure as throwing a password
around and using sudo and invoking layers of quoting hell.
But let's say it's not either of these things. Maybe it's a database
access password or something, and you're actually doing something like:
sshnonr...@some.host 'mysql -p mydatabase ...'
The obvious play here is to send the password on stdin. But you've
introduced another layer of complication, because you're actually doing
something like:
sshnonr...@some.host bash <<-EOF
some command
another command
mysql -p"$injected_password" mydatabase
EOF
where stdin is already tied up sending the script for bash to execute,
and therefore can't be used to send the database password. This is NOT
going to work.
What you want to do instead is pass the password as an *argument* to
bash -s. You've already got the @Q (or printf %q) part, which is a
necessary step. You just need the rest of it.
sshnonr...@some.host bash -s "${password@Q}"
Docs: Mention that hash resets after changing PATH
Hello, I noticed that there's no mention in the manual that, when the PATH changes, "hash -r" is run. I think that would be a nice addition, possibly on "4.1 Bourne Shell Builtins / hash" Thanks.
history-size reported as "0" even is value is "-1"
Hello, history-size is documented as follows: > If set to a value less than zero, the number of history entries is not limited. But after setting it to "-1", for example with this line in .inputrc: > set history-size -1 It is still reported as "0" in "bind -v": > set history-size 0 Nevertheless, it's clear that the actual value is not zero because, for example, history entries are not deleted. Thanks.
Some Readline variables are not available in "bind -v"
Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color - isearch-terminators Thanks for your time.
Docs: "shell-transpose-words" in "8.4.4 Killing And Yanking"
Hello, The "shell-transpose-words" command is documented in the section "8.4.4 Killing And Yanking", but I think it should be in "8.4.3 Commands For Changing Text". That way, just like the other "shell-*" commands, it would be documented next to its counterpart "transpose-words". Thanks.
Re: bash tab variable expansion question?
Am 02.09.2011 21:32, schrieb Chet Ramey:
On 2/24/11 5:14 PM, Michael Kalisz wrote:
Bash Version: 4.2
Patch Level: 0
Release Status: release
Description:
Hi!
Example:
In bash, version 4.1.5(1)-release:
$ echo $PWD/
will expand the $PWD variable to your current directory
while in bash, version 4.2.0(1)-release:
$ echo $PWD/
will just escape the $ in front of the $ variable i.e:
$ echo \$PWD/
The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB
Any hints why? Any way to get the 4.1 behavior in 4.2?
I wrote, in a subsequent message in a related thread:
The difference is that bash-4.1 expanded $HOME and left the expansion
as part of the replacement text. Bash-4.2 tries to leave what the
user typed alone, but that leads to an inherently ambiguous situation:
when do you quote the `$' in a filename (or, in this case, a directory
name)? It could be a shell variable, and it could be a character in
the filename.
That is the problem, in a nutshell. I posted a partial patch at the
end of March that applied a heuristic to avoid quoting variable
expansions in most cases, but there was no way to get the bash-4.1
behavior back.
The attached patch adds a new shell option that, when enabled, is
intended to restore the bash-4.1 behavior of expanding directory names
in filenames being completed. I have done some testing, and it seems
to work the way I intend. This, or some later version, will be part
of the next bash release. I am soliciting feedback on this iteration.
I'm sending this directly to everyone who's commented negatively about
the default bash-4.2 behavior, as well as bug-bash. Please try the new
option (`direxpand') and let me know if it's missing anything. The patch
includes the original heuristic I sent out back in March, the new shopt
option, and updates to the documentation and test suite. It should apply
cleanly to bash-4.2.10.
Chet
Hi Chet,
Thanks for the great patch.
I have applied your patch in our bash 4.2 + Patchlevel 20. It is solved
an issue with variable expansion. But on the other side bash completion
is broken. :-(
Bash completion with local file (./some_script.sh, e.g.) would not be
working:
# ./some_sc
Current result:
# ./some_sc
Expected result:
# ./some_script.sh
It seems that the bash completion stops working.
I have added another patch to fix this issue. It would be nice if you
have a look to the patch and let me know if this is ok.
Thank you.
--
Kind regards, Sebastian - openSUSE Member (Freespacer)
Website/Blog: <http://www.sebastian-siebert.de>
Important notes on openSUSE Mailing List:
<http://en.opensuse.org/openSUSE:Mailing_list_netiquette>
diff -rup bash-4.2.orig/bashline.c bash-4.2/bashline.c
--- bash-4.2.orig/bashline.c 2012-02-29 10:28:32.196236258 +0100
+++ bash-4.2/bashline.c 2012-02-29 12:57:15.071591691 +0100
@@ -2722,7 +2722,7 @@ set_directory_hook ()
if (dircomplete_expand)
{
rl_directory_completion_hook = bash_directory_completion_hook;
- rl_directory_rewrite_hook = (rl_icppfunc_t *)0;
+ rl_directory_rewrite_hook = bash_directory_completion_hook;
}
else
{
Re: bash tab variable expansion question?
On 05.03.2012 21:28, Chet Ramey wrote: On 3/5/12 2:07 PM, Sebastian Siebert wrote: Thanks for the great patch. I have applied your patch in our bash 4.2 + Patchlevel 20. It is solved an issue with variable expansion. But on the other side bash completion is broken. :-( Bash completion with local file (./some_script.sh, e.g.) would not be working: # ./some_sc Current result: # ./some_sc Expected result: # ./some_script.sh It seems that the bash completion stops working. I have added another patch to fix this issue. It would be nice if you have a look to the patch and let me know if this is ok. Thanks. This is not the correct fix for that particular problem. Please look at the `direxpand' branch of the bash git tree at http://git.savannah.gnu.org/cgit/bash.git/?h=direxpand for a version of bash-4.2.20 with an updated direxpand patch applied. This problem is fixed there. Chet Hi Chet, thank you to point me out to the correct patch. :-) I will used this patch for the bash 4.2 + PL 20. -- Kind regards, Sebastian - openSUSE Member (Freespacer) Website/Blog: <http://www.sebastian-siebert.de> Important notes on openSUSE Mailing List: <http://en.opensuse.org/openSUSE:Mailing_list_netiquette>
Can't get the set-user-id bit to work
Hi all, If it's a festive time of year where you are then I hope you're enjoying it. First of all, apologies if this is not the correct list for this query. Perhaps you could suggest where else I should go. I have a 3-line script; foo: #!/bin/bash id -u # EUID id -u -r # `real' UID Here's it's directory listing: -rwsrwxr-- 1 root adm 1317 Dec 27 16:18 foo I set these permissions with the command: $ sudo chmod 4774 foo Here's what I get if I run foo as myself (UID 1000): $ ./foo 1000 1000 Surely this should be: $ ./foo 0 1000 ... or am I missing the point somehow? I started to investigate the behaviour of the set-user-id bit because of another problem I've been experiencing for some time: A cron.daily script handles mandb. I elected to install it with the set-user-id bit set, as you can see: /usr/lib/man-db: used 220 available 573264 drwxr-xr-x2 root root 4096 Oct 16 15:13 . drwxr-xr-x 116 root root 24576 Dec 14 11:49 .. -rwsr-xr-x1 man root 86932 Sep 21 13:23 man -rwsr-xr-x1 man root 96808 Sep 21 13:23 mandb Every day I receive the same message in my inbox: /etc/cron.daily/man-db script: mandb: can't create a temporary filename: Permission denied mandb is a binary executable file so I have no idea where it is trying to create the temporary file, but it certianly shouldn't have any trouble creating it in /tmp: drwxrwxr-x 13 root root 4096 Dec 27 16:50 /tmp Any help with either of these issues is very much appreciated. sdt -- GNU bash, version 3.1.0(1)-release (i486-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Can't get the set-user-id bit to work
[EMAIL PROTECTED] (Paul Jarc) wrote:
> Sebastian Tennant <[EMAIL PROTECTED]> wrote:
>> I have a 3-line script; foo:
>
> The setuid bit works only for binaries, not scripts. This is a
> limitation of the kernel, necessary for security.
Ah. I read the chmod manpage and some stuff in the find Info manual
on permissions, and this fact is not made immediately apparent.
Perhaps it should be. Or perhaps I'm just not seeing :-/
>> A cron.daily script handles mandb. I elected to install it with the
>> set-user-id bit set, as you can see:
>
> Is it meant to be installed that way? If not, you probably shouldn't
> do that. It might break something, or introduce a security risk.
Debian's debconf mechanism currently presents you with the option:
"The man and mandb program can be installed with the set-user-id
bit set, so that they will run with the permissions of the 'man'
user. This allows ordinary users to benefit from the caching of
preformatted manual pages ('cat pages'), which may aid performance
on slower machines.
Cached man pages only work if you are using an 80-column terminal,
to avoid one user causing cat pages to be saved at widths that
would be inconvenient for other users. If you use a wide terminal,
you can force man pages to be formatted to 80 columns anyway by
setting MANWIDTH=80.
Enabling this feature may be a security risk, so it is disabled by
default. If in doubt, you should leave it disabled.
Should man and mandb be installed 'setuid man'?"
I set it this way in an attempt to overcome the problem I was having.
Now that I know what the problem is I'll revert to non SUID man.
> With those permissions, only the root user and root group can create
> files in /tmp. To allow all users to create files there, make it
> world-writable and sticky:
> # chmod 1777 /tmp
> # ls -ld /tmp
> drwxrwxrwt 13 root root 4096 Dec 27 16:50 /tmp
OK, but mandb _is_ a member of the root group, so shouldn't it be able
to write files in /tmp with the permissions as they stand?
-rwsr-xr-x1 man root 96808 Sep 21 13:23 mandb
drwxrwxr-x 13 root root 4096 Dec 27 16:50 /tmp
sdt
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Can't get the set-user-id bit to work
[EMAIL PROTECTED] (Paul Jarc) wrote: > Sebastian Tennant <[EMAIL PROTECTED]> wrote: >> OK, but mandb _is_ a member of the root group, so shouldn't it be able >> to write files in /tmp with the permissions as they stand? > > No, you'd have to make it setuid to root, or setgid to the root > group. The user/group associations in /etc/passwd and /etc/group > aren't involved. OK. I get it. Ta. sdt ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
DEBUG trap and job names
Hello dear bash-bug readers, I'm quite sure I have found a micro-bug in the bash which should take about two lines of code to fix -- if you know where to put them. I tried to locate the problem myself, but the innards of bash traps remain a mystery to me. Anyway, the description is here: https://launchpad.net/distros/ubuntu/+source/bash/+bug/41082 For your convenience, I'm replicating the report here: >>>>> When a DEBUG trap is set, it overwrites the current foreground job's job name (name as seen in the 'jobs' listing). Reproduction: 1. set trap, e.g. trap echo DEBUG 2. launch foreground process 3. Ctrl+Z to background it 4. type 'jobs' Example: sh-3.1$ sleep 600 & [1] 2870 sh-3.1$ jobs [1]+ Running sleep 600 & sh-3.1$ fg sleep 600 [1]+ Stopped(SIGTSTP) sleep 600 sh-3.1$ trap echo DEBUG sh-3.1$ fg sleep 600 [1]+ Stopped(SIGTSTP) sleep 600 sh-3.1$ sleep 600 [2]+ Stopped(SIGTSTP) echo sh-3.1$ jobs [1]- Stopped(SIGTSTP) sleep 600 [2]+ Stopped(SIGTSTP) echo sh-3.1$ <<<<< Obviously, both job names should be "sleep 600" since the echo has already executed and is in a trap anyway. I would be very grateful if someone in the know would spend a few thoughts on this one :-) For the record: I'm running bash version "3.1.17(1)-release", at least that's what Ubuntu calls it, should be up-to-date. -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
readline post-hook?
Is there a way to run a function after the user has finished a line with RETURN to add characters to the readline buffer? Of course one could malloc new memory and copy the stuff got by the call of readline but may be there is a more smart way of doing it? Thanks for your help! Sebastian ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.2, escape sequences
Hi Chet, hi bug-bash readers, I'm not quite getting the changes in bash's handling of escape sequences. [EMAIL PROTECTED](~)> echo '\a' '\a Ouch? This is not related to escape sequence handling: [EMAIL PROTECTED](~)> echo -E '\a' '\a [EMAIL PROTECTED](~)> echo -e '\a' ' And yet, it is: [EMAIL PROTECTED](~)> echo '\\ \ \ \ ' \\ \ \ \ [EMAIL PROTECTED](~)> echo '\\ \a \ \ ' \ \ '\\ \a \ \ [EMAIL PROTECTED](~)> echo 'wow\awow' wow'wow\awow [EMAIL PROTECTED](~)> echo $'\a' ' [EMAIL PROTECTED](~)> echo \\a \a Finally! [EMAIL PROTECTED](~)> echo $BASH_VERSION 3.2.5(1)-release [EMAIL PROTECTED](~)> gcc --version gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Sorry if I'm being terribly ignorant here, but I don't get it. On a related note, the documented escape sequences handled by "echo" differ between help echo and man echo (-e vs. -E). -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash 3.2, escape sequences
> Sebastian Kapfer wrote: > >> I'm not quite getting the changes in bash's handling of escape >> sequences. > > I can't reproduce your results: [...] > I suspect that you have echo defined as a function or alias, or > something in $PROMPT_COMMAND or $PS1 is obscuring the output. Oops, I thought I had disabled that stuff. Well, you always overlook the essential. :-( >> On a related note, the documented escape sequences handled by "echo" >> differ between help echo and man echo (-e vs. -E). > > Well, they document different programs. `help echo' describes the > bash builtin, and `man echo' describes /bin/echo. Sorry, I mean, the descriptions of help echo and man bash differ. Thank you for your help! Best regards, Sebastian ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: "C-z bg" without the lurch
Am Mittwoch, den 26.11.2008, 09:51 +0800 schrieb [EMAIL PROTECTED]: > There are many times one has not planned ahead, and forgets the &: > $ emacs -nw important.txt #then after a half an hour of editing: > ^Z > [1]+ Stopped emacs -nw important.txt > $ compact_disk_burner_GUI_application #forgot to add & [...] > Anyway, how could it be that the mighty bash can't let me get back to > my emacs without lurching my CD burning job, even for a split second? This doesn't really answer your question, but one solution is: In another xterm (I assume this is X11): pkill -CONT emacs This does work for programs that don't insist on reading from the TTY they're on, which is probably true for the X11 version of Emacs (I prefer more spartanic editors myself *g*). -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread!
Re: globstar syntax
Am Montag, den 19.01.2009, 10:14 -0800 schrieb Alex Reed:
> 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
Huh?
So what's the difference between the following two lines
echo **
echo `find`
Quoting?
--
Best Regards, | Hi! I'm a .signature virus. Copy me into
Sebastian | your ~/.signature to help me spread!
Re: Is this bash-doable job?
On Do, 2009-06-18 at 16:14 -0700, Jindan Zhou wrote: > I am a bash beginner, just started to build a script that does: > > 1. Check if a BBS type site has any new posts, the new thread URL pattern is > http://www.example.com/bbsviewer.php?trd_id=123456 > > 2. If 1 is true, go into that URL, find a file link of the pattern > http://www.example.com/upload_music/4153216.mp3 > > 3. If the link in 2 exist, download it to a directory. Actually, this has very little to do with bash. bash is a UNIX shell and provides the glue between other tools. In your case, the tool is probably something like GNU wget, which can be driven from bash. > Can someone kindly point me to a direction to accomplish this? Is there > better way to do, like PHP? PHP is best known for server-side web programming, and I don't think it would be better suited for your problem than any other programming language. -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread!
Text cursor hangs/freezes, 2 x backspace unfreezes
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: solaris2.9 Compiler: /opt/studio/SOS12/SUNWspro/bin/cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='solaris2.9' -DCONF_MACHTYPE='i386-pc-solaris2.9' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/csw/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DSOLARIS -I. -I. -I./include -I./lib -I/opt/csw/include -xO3 -m32 -xarch=386 -xnorunpath uname output: SunOS ray3 5.10 Generic_141445-09 i86pc i386 i86pc Machine Type: i386-pc-solaris2.9 Bash Version: 4.1 Patch Level: 5 Release Status: release Description: I am using bash 4.1.5 on Solaris 10 x86 (binary from opencsw.org built on Solaris 9) in an xterm 243. Every now and then the text cursor "freezes", i.e. subsequent keyboard input doesn't show up. truss'ing the bash process shows that it's still reading the keys, but it doesn't process/display them. $ truss -p 26716 read(0, 0x08047534, 1) (sleeping...) read(0, " a", 1)= 1 read(0, " s", 1)= 1 read(0, " d", 1)= 1 read(0, " f", 1)= 1 read(0, " ", 1)= 1 read(0, " ", 1)= 1 read(0, " ", 1)= 1 read(0, 0x08047534, 1) (sleeping...) read(0, " 1", 1)= 1 read(0, " 2", 1)= 1 read(0, " 3", 1)= 1 read(0, " 4", 1)= 1 read(0, 0x08047534, 1) (sleeping...) Hitting backspace twice "unfreezes" the cursor and everything is back to normal. Previously entered characters don't show up, but new ones do. ... read(0, "\b", 1)= 1 read(0, "\b", 1)= 1 write(2, "\b1B [ K", 4) = 4 read(0, 0x08047534, 1) (sleeping...) read(0, " ", 1)= 1 write(2, " ", 1) = 1 read(0, " ", 1)= 1 ... The binary hasn't been built with debugging symbols. When the issue occurs, the stack trace looks like below. The issue is nothing specifically new to 4.1.5, I also ran into it with previous versions. Please let me know if you need any additional information. $ pstack core.26716 core 'core.26716' of 26716: -bash fee09ff7 read (0, 8047534, 1) 080b8c21 rl_getc (80f6dd8) + 1f 080b8be7 rl_read_key (0, 804755c, 80aba46, 8047564, 80aba60, 8047570) + ad 080ab914 readline_internal_char (8047564, 80aba60, 8047570, 80ab6fe, 808b5d6, 8047580) + 5c 080aba46 (8047570, 80ab6fe, 808b5d6, 8047580, 8067595, 8113e08) 080aba60 (808b5d6, 8047580, 8067595, 8113e08, 8047770, 8047588) 080ab6fe readline (8113e08) + 37 08067595 (804759c, 8067d13, 0, 80475e0, 8047770, 80475b0) 0806750d (0, 80475e0, 8047770, 80475b0, 806869c, 1) 08067d13 (1) 0806869c (0) 0806825d (0, 0, 0, 80feea8, 0, 8102000) 08065e05 yyparse (0, 8047de8, 8065c7c, 0, 0, 0) + 12f 08065bd9 parse_command (0, 0, 0, 0, 8047dfc, 80659f9) + 56 08065c7c read_command (0, 0, 1, 8047e1c, 8064010, 8047e84) + 8c 080659f9 reader_loop (8047e84, 8047e04, feffb818, 1, 0, 1) + dd 08064010 main (1, 8047e48, 8047e50) + 638 08063942 (1, 8047eec, 0, 8047ef2, 8047eff, 8047f0f) Repeat-By: Sorry, couldn't yet narrow down how this issue can be triggered.
Feature request: alternating keys & values syntax for hashes
Hello
The current syntax for hashes doesn't allow interaction between arrays
and hashes. The syntax that would allow it is simple dump of the keys
and values alternating and acceptance of such series of values at
assignment of the hash.
This syntax is long used in Zsh. Example code:
declare -a array=( a 1 b 2 c 3 )
declare -A hash=( ${array[@]} )
declare -p hash
=> typeset -A hash=( [a]=1 [b]=2 [c]=3 )
declare -a array2=( ${(kv)hash[@]} )
declare -p array2
==> typeset -a array2=( a 1 b 2 c 3 )
This has many useful use cases e.g. when doing an advanced, fork-(i.e.
also: subshell) free shell coding. Consider e.g. a fork-free
serialization of an array:
array=( val1 "val2*[special-chars]" )
printf -v serialized "%q " "${array[@]}"
eval "deserialized=($serialized)"
With the new syntax it would be possible to serialize and deserialize
hashes in the same way (the *-char is the example new syntax to dump
k&v alternating):
declare-A hash=( [key1]=val1 ['key2*[special-chars]']=val2 )
printf -v serialized "%q " "${*hash[@]}"
typeset -A deserialized_hash
eval "deserialized_hash=($serialized)"
This is a one particular example use case, but I'm using array<->hash
interaction on a regular basis in Zsh.
The syntax-extension is of most-easy kind, it actually doesn't change
anything (besides the *-like addition to the var flags, i.e. the
${*hash[@]}, to dump k&v-s), it's just about allowing hashes to accept
series of values, being the k&v-s alternating. Is there a chance for
such an extension?
PS. The *-symbol might be the right choice, as it inherits the glob
meaning "match all", and this translates to the hash variable "give
back all, i.e. values AND keys".
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
