Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion
thank you for your answers, i reported such bug to the bash-completion package holder. Regards. On 20-12-2016 18:29, Chet Ramey wrote: On 12/20/16 1:24 PM, Eduardo Bustamante wrote: I cannot reproduce this on bash 4.4: They probably have something defined as the default completer using `complete -D', and that probably tries to add a compspec for it by blindly sticking `command' in front of the word to be completed.
Re: ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
Hello Chet and Eduardo, thank you very much for your replies. Everything is crystal clear now. Sorry for the 'wrong alarm' (: Best, Nick On 20/12/2016 20:24, Chet Ramey wrote: On 12/20/16 11:11 AM, Nick wrote: i came up with a weird behavior of ssh+bash on my Debian box (8.6). I created an alias in /etc/bash.bashrc file, which is sourced through /etc/profile. Everything worked fine, till i decided to remove the '. /etc/bash.bashrc' line from /etc/profile. When i` m connected via ssh the '/etc/bash.bashrc' is not sourced and the alias does not work as expected. But, when i execute bash from my shell, the '/etc/bash.bashrc' seems to be sourced and the alias is there (please find bellow a demo) ssh without a command is equivalent to slogin, which starts a login shell on the remote host. Login shells don't execute ~/.bashrc (and, if so configured, SYS_BASHRC), so there's usually a line to source it in one of the login shell startup files (/etc/profile in your case). That's why it's there, and that's why removing it had the effect you observed. Not sure if i miss something (f.x. bash is executed with different flags while being called from ssh versus a user), but as far as i understand, the same things should be (or not) sourced. Well, it's the difference between a login shell and a non-login interactive shell.
Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion
On 12/20/16 1:24 PM, Eduardo Bustamante wrote: > I cannot reproduce this on bash 4.4: They probably have something defined as the default completer using `complete -D', and that probably tries to add a compspec for it by blindly sticking `command' in front of the word to be completed. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
On 12/20/16 11:11 AM, Nick wrote: > i came up with a weird behavior of ssh+bash on my Debian box (8.6). > I created an alias in /etc/bash.bashrc file, which is sourced through > /etc/profile. > Everything worked fine, till i decided to remove the '. > /etc/bash.bashrc' line from /etc/profile. > When i` m connected via ssh the '/etc/bash.bashrc' is not sourced and > the alias does not work as expected. > But, when i execute bash from my shell, the '/etc/bash.bashrc' seems > to be sourced and the alias is there (please find bellow a demo) ssh without a command is equivalent to slogin, which starts a login shell on the remote host. Login shells don't execute ~/.bashrc (and, if so configured, SYS_BASHRC), so there's usually a line to source it in one of the login shell startup files (/etc/profile in your case). That's why it's there, and that's why removing it had the effect you observed. > Not sure if i miss something (f.x. bash is executed with different > flags while being called from ssh versus a user), but as far as i understand, > the same things should be (or not) sourced. Well, it's the difference between a login shell and a non-login interactive shell. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion
I cannot reproduce this on bash 4.4:
dualbus@yaqui:~$ { for i in '-i' '\t' '\t' '\t' '\n' 'exit\n'; do
sleep 1; printf -- "$i"; done } | script --command 'bash --norc
--noprofile'
Script started, file is typescript
bash-4.4$ -i
bash: -i: command not found
bash-4.4$ exit
exit
Script done, file is typescript
dualbus@yaqui:~$ bash --version
GNU bash, version 4.4.0(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Do you have the bash-completion package installed? It sounds like the
bug is in that package, which is external to the GNU bash project
(https://github.com/scop/bash-completion)
Re: ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
Please read http://mywiki.wooledge.org/DotFiles#Remote_shell_logins (perhaps read http://mywiki.wooledge.org/DotFiles#Console_logins first). The key to understanding this is to know that there are three basic types of shell startup: - Login shell - Interactive shell - Non-login Non-interactive shell (scripts and -c) Each of these startup modes source different files. You need to make sure you layout your initialization files with that in mind.
ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
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='$ uname output: Linux katastrofi 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: Hello, i came up with a weird behavior of ssh+bash on my Debian box (8.6). I created an alias in /etc/bash.bashrc file, which is sourced through /etc/profile. Everything worked fine, till i decided to remove the '. /etc/bash.bashrc' line from /etc/profile. When i` m connected via ssh the '/etc/bash.bashrc' is not sourced and the alias does not work as expected. But, when i execute bash from my shell, the '/etc/bash.bashrc' seems to be sourced and the alias is there (please find bellow a demo) Not sure if i miss something (f.x. bash is executed with different flags while being called from ssh versus a user), but as far as i understand, the same things should be (or not) sourced. Best, Nick Please find /etc/bash.bashrc, /etc/profile and my home directory under this link: www.katastrofi.eu/nick.tar.gz # Demo root@RBMK-1000:~# ssh nick@10.250.251.12 ssh nick@10.250.251.12 nick@10.250.251.12's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Dec 20 17:29:37 2016 from 10.250.251.238 bla nick@RBMK-1000:~$ ll -bash: ll: command not found nick@RBMK-1000:~$ bash nick@RBMK-1000:~$ ll total 24 drwxr-xr-x 2 nick nick 4096 Dec 20 17:28 . drwxr-xr-x 3 root root 4096 Dec 13 22:06 .. -rw--- 1 nick nick 195 Dec 20 17:29 .bash_history -rw-r--r-- 1 nick nick 220 Nov 4 12:58 .bash_logout -rw-r--r-- 1 nick nick 3515 Nov 4 12:58 .bashrc -rw-r--r-- 1 nick nick 675 Nov 4 12:58 .profile nick@RBMK-1000:~$ # nick login shell nick@katastrofi:~$ grep nick /etc/passwd nick:x:1000:1000:,,,:/home/nick:/bin/bash nick@katastrofi:~$ # OS nick@RBMK-1000:~$ uname -a Linux RBMK-1000 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux nick@RBMK-1000:~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.6 (jessie) Release:8.6 Codename: jessie nick@RBMK-1000:~$ # Packages installed nick@RBMK-1000:~$ dpkg -l | grep bash ii bash 4.3-11+b1 amd64 GNU Bourne Again SHell ii bash-completion1:2.1-4 all programmable completion for the bash shell nick@RBMK-1000:~$ dpkg -l | grep ssh ii libssh2-1:amd641.4.3-4.1+deb8u1amd64 SSH2 client-side library ii openssh-client 1:6.7p1-5+deb8u3amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:6.7p1-5+deb8u3amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server1:6.7p1-5+deb8u3amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines ii python-paramiko1.15.1-1all Make ssh v2 connections with Python (Python 2) ii task-ssh-server3.31+deb8u1 all SSH server nick@RBMK-1000:~$
Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion
I was running it on a Ubuntu 14.04 LTS machine; the bug occurred when i inputed $ -i and i proceeded with a TAB and it returned this: $ -i bash: complete: -i: invalid option complete: usage: complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action] [-G globpat] [-W wordlist] [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] [name ...]
Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion
I was running it on a Ubuntu 14.04 LTS machine; the bug occurred when i inputed $ -i and i proceeded with a TAB and it returned this: $ -i bash: complete: -i: invalid option complete: usage: complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action] [-G globpat] [-W wordlist] [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] [name ...]
Re: bug report
On Tue, Dec 20, 2016 at 12:39:12PM +, Hossein Vatani wrote: > Hi experts,I encountered a issue that i guessed a bug.i tried to make bash > script that generate strong password and save it with htpasswd command.if i > generate er"exc'oti!ot for password, i could not send it as string to > htpasswd and more strong, in command line i has this problem too."-bash: > !ot": event not found"i'm sure after solving above message i'ld faced > message(actualy not message)> > best regards.P.S. sorry for my english. it isn't my native language. :-) It sounds like you've got csh-style history expansion enabled, which should not be the default behavior in a script. (It *is* the default in an interactive shell.) Try disabling it with "set +o histexpand". If you're actually working with an interactive shell and don't want to give up history expansion (even temporarily), you will just have to figure out how to work around the quoting hell you're stuck in. Try using single quotes instead of double quotes, or using $'...' quoting with backslash-escaped inner single quotes, or whatever it takes. I found it a lot easier just to: imadev:~$ head -2 .bashrc set -o vi set +o histexpand
bug report
Hi experts,I encountered a issue that i guessed a bug.i tried to make bash script that generate strong password and save it with htpasswd command.if i generate er"exc'oti!ot for password, i could not send it as string to htpasswd and more strong, in command line i has this problem too."-bash: !ot": event not found"i'm sure after solving above message i'ld faced message(actualy not message)> best regards.P.S. sorry for my english. it isn't my native language. :-)
