Re: autocd doesn't invoke customized `cd` wrapper

[Chet Ramey]

On 1/1/16 4:41 PM, transl8cz...@gmail.com wrote:

> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
> 
> Description:
>   If `cd` is a function or an alias in my environment, I think autocd ought 
> to invoke
>   that instead of the raw `command cd` (like it does now).

Invoking a function would be reasonable, since you don't have to mess with
special builtins and search order in Posix mode.  Since alias expansion is
performed when the command is read, not when it is executed, it's the wrong
place to do that.  I'll take a look at it for bash-4.4.

Chet

-- 
``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/

Re: Running bash using su -c causes 100% cpu usage on one core

[Chet Ramey]

On 1/3/16 6:27 PM, Marcus Wichelmann wrote:
> Hi,
> 
> Im not sure if this is a regression because I already found another bug 
> report with the same symptoms from 2007, but when adding this line to the 
> /etc/rc.local the cpu usage of one of the two cores raises to 100%:
> 
> su cubie -c "(cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh)" &

There's not enough information here to say anything for sure, but it might
be that run.sh does not behave well when called without a controlling
terminal.

-- 
``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/

Re: Uniq pattern

[Greg Wooledge]

On Thu, Dec 31, 2015 at 06:44:07PM -0600, John McKown wrote:
> On Thu, Dec 31, 2015 at 6:15 PM, Val Krem  wrote:
> > I wanted to search a line  that contains  "1235"  using
> > grep   -R "1235".
> > I am getting  unwanted results such as
> >  01235 or 12356 and so on.
> >
> > How could I avoid these and get only '1235"?
> 
> I don't know what you mean by "only 1235". Do you mean with no leading or
> trailing digits? I.e. A1235B is a match, but 01235 is not. Or do you mean
> "a line which contains _only_ 1235 and no other characters?
> 
> For the first, this should work: egrep
> '(^|[^[:digit:]])1235($|[^[:digit:]])'
> 
> ({^|[^[:digit:])) matches the beginning of the ???string (^) or a non-digit
> [^[:digit:]]
> then the digits "1235
> ($|[^[:digit:]]) then matches the end of the string ($) or a non-digit.

Those are possible interpretations, but I can think of others.

"A line containing only 1235" is the easiest case, so let's get that one
out of the way:

  grep -Fx 1235

"Lines containing 1235 as a space-delimited word" is the more likely
question.  That one is "easier" if you are using GNU grep with its
perl-ish extensions.  But let's assume POSIX grep.  The word 1235
can appear with spaces on both sides, or it can be at the start of
the line (with or without trailing spaces), or it can be at the
end of the line (with or without leading spaces).

  grep -E '(^|[[:space:]])1235($|[[:space:]])'

That matches 1235 with either start-of-line or a space before it,
and with either end-of-line or a space after it.

For Val, please be as clear as you can possibly be with your questions.
It's best to provide example inputs, especially tricky or subtle examples
that clearly draw the line between what you want and what you don't want.

> Oh, what does this have to do with BASH? And how is it a bug? IOW, this
> looks like the wrong forum. This is not a general UNIX (or Linux) question
> and answer forum. You might want to get an account on StackExchange
> http://stackexchange.com/

Yes and no.  While help-b...@gnu.org is a more appropriate forum for
this kind of question, bug-bash was also used this way for many years.
All we can do is gently steer people toward help-bash.

Re: Running bash using su -c causes 100% cpu usage on one core

[Marcus Wichelmannn]

Am Mo, 4. Jan, 2016 um 2:51 schrieb Eduardo A. Bustamante López 
:
It's impossible to tell with the amount of info you provided. That's 
why
there's a 'bashbug' script alongside bash to generate a useful bug 
report

template.

Provide:

- bash version: bash --version
- OS name and version: uname -a
- The contents of the run.sh file
- If possible also the su version (in my case it doesn't have a 
version flag,

but it's part of the login package).
- The output of running said script, with 'set -x' enabled

You might not be running bash at all, since you didn't explictly 
called
/bin/bash, instead letting su run /bin/sh, which could be dash, or 
any other

shell.

--
Eduardo Bustamante
https://dualbus.me/


Oh, didn't know this script exists, thank you.. ;)
Here are some more information:


Configuration Information [Automatically generated, do not change]:
Machine: arm
OS: linux-gnueabihf
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='arm' 
-DCONF_OSTYPE='linux-gnueabihf' 
-DCONF_MACHTYPE='arm-unknown-linux-gnueabihf' -DCONF_VENDOR='unknown' 
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H $
uname output: Linux HAUS-STEUERUNG 3.4.100-sun7i+ #1 SMP PREEMPT Tue 
Jul 29 13:25:24 CEST 2014 armv7l GNU/Linux

Machine Type: arm-unknown-linux-gnueabihf

Bash Version: 4.3
Patch Level: 30
Release Status: release


/etc/rc.local contains (the issue occurs without the "-s /bin/sh", too):


#!/bin/sh -e

alias ls="ls --color"

echo 0 > /sys/class/leds/green\:ph20\:led1/brightness

su cubie -c "(cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh)" 
-s /bin/sh &


exit 0


run.sh contains:


#!/bin/sh

./Haussteuerung >> log 2>&1
bash mailnotify.sh "Unerwarteter Fehler" "Das Haussteuerungsprogramm 
wurde unerwartet beendet! Siehe Anhang fuer weitere Informationen." 
log


"Haussteuerung" is a compiled mono executable.

Information about the "login" package:


login:
  Installiert: 1:4.1.5.1-1
  Installationskandidat: 1:4.2-3
  Versionstabelle:
 1:4.2-3 0
500 http://ftp.de.debian.org/debian/ stable/main armhf 
Packages

 *** 1:4.1.5.1-1 0
100 /var/lib/dpkg/status


When executing run.sh with the -x parameter the output is only


+ ./Haussteuerung


And /etc/rc.local prints:


sudo /etc/rc.local
+ alias ls=ls --color
+ echo 0
+ exit 0
+ su cubie -c (cd /home/cubie/Haussteuerung/Haussteuerung; ./run.sh) 
-s /bin/sh


Output from htop (the first process has a cpu usage of 100%):


PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.44 /usr/bin/cli 
./Haussteuerung
2206 cubie 20 0 44168 15484 7552 S 1.4 1.7 0:05.98 /usr/bin/cli 
./Haussteuerung
2081 root 20 0 3884 1324 988 S 0.0 0.1 0:00.03 su cubie -c (cd 
/home/cubie/Haussteuerung/Haussteuerung; ./run.sh) -s /bin/sh


When running run.sh directly in the terminal the cpu usage is at 2%. 
The "Haussteuerung" executable works correctly in both cases.


I hope this information helps.

Marcus

Re: Running bash using su -c causes 100% cpu usage on one core

[Chet Ramey]

On 1/4/16 9:01 AM, Marcus Wichelmannn wrote:
utput from htop (the first process has a cpu usage of 100%):
> 
>> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
>> 2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.44 /usr/bin/cli
>> ./Haussteuerung

What is /usr/bin/cli?  It's the program that is using the CPU.

-- 
``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/

Re: Running bash using su -c causes 100% cpu usage on one core

[Marcus Wichelmannn]

Am Mo, 4. Jan, 2016 um 3:32 schrieb Chet Ramey :

On 1/4/16 9:01 AM, Marcus Wichelmannn wrote:
utput from htop (the first process has a cpu usage of 100%):



 PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
 2199 cubie 20 0 44168 15484 7552 R 101. 1.7 11:45.44 /usr/bin/cli
 ./Haussteuerung


What is /usr/bin/cli?  It's the program that is using the CPU.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/


Afaik it's a symlink to /usr/bin/mono.

I solved my issue by replacing the line in /etc/rc.local by:

su cubie -c "screen -S Haussteuerung -d -m 
/home/cubie/Haussteuerung/Haussteuerung/run.sh"


But this is no fix of this bug for sure.

Re: Running bash using su -c causes 100% cpu usage on one core

[Greg Wooledge]

On Mon, Jan 04, 2016 at 07:03:39PM +0100, Marcus Wichelmannn wrote:
> Am Mo, 4. Jan, 2016 um 3:32 schrieb Chet Ramey :
> >What is /usr/bin/cli?  It's the program that is using the CPU.
> 
> Afaik it's a symlink to /usr/bin/mono.
> 
> I solved my issue by replacing the line in /etc/rc.local by:
> 
> su cubie -c "screen -S Haussteuerung -d -m 
> /home/cubie/Haussteuerung/Haussteuerung/run.sh"
> 
> But this is no fix of this bug for sure.

If mono (aka cli) runs away eating all CPU when it's launched without
a terminal, then this isn't a bash bug, but rather a mono bug.  And
your workaround is a good one.

Feature: Easily remove current command from history

[porton]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -D_FORTIFY_SOURCE=2 -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall
uname output: Linux victor.local 4.1.0-2-686-pae #1 SMP Debian 4.1.6-1 
(2015-08-23) i686 GNU/Linux
Machine Type: i586-pc-linux-gnu

Bash Version: 4.3
Patch Level: 42
Release Status: release

Description:

There should be an easy way to remove the currently selected command
from the history.

Fix:

I propose to add new readline command which when it is invoked removed the
current shell command from the history and moves to either the next or the
previous command (not sure whether next of previous).

Re: Running bash using su -c causes 100% cpu usage on one core

[Chet Ramey]

On 1/4/16 1:03 PM, Marcus Wichelmannn wrote:

> Afaik it's a symlink to /usr/bin/mono.
> 
> I solved my issue by replacing the line in /etc/rc.local by:
> 
> su cubie -c "screen -S Haussteuerung -d -m
> /home/cubie/Haussteuerung/Haussteuerung/run.sh"
> 
> But this is no fix of this bug for sure.

Maybe not, but it's not a bash bug.

-- 
``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/

Re: Feature: Easily remove current command from history

[Chet Ramey]

On 1/4/16 1:30 PM, por...@narod.ru wrote:

> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
> 
> Description:
> 
> There should be an easy way to remove the currently selected command
> from the history.

Easier than `history -d'?

-- 
``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/

Re: Feature: Easily remove current command from history

[Victor Porton]

On Mon, 2016-01-04 at 14:59 -0500, Chet Ramey wrote:
> On 1/4/16 1:30 PM, por...@narod.ru wrote:
> 
> > Bash Version: 4.3
> > Patch Level: 42
> > Release Status: release
> > 
> > Description:
> > 
> > There should be an easy way to remove the currently selected
> > command
> > from the history.
> 
> Easier than `history -d'?
Look into my proposal carefully: I propose to do an equivalent of
`history -d' with user pressing a single key.


-- 
Victor Porton - http://portonvictor.org

Re: Feature: Easily remove current command from history

[Chet Ramey]

On 1/4/16 3:09 PM, Victor Porton wrote:
> On Mon, 2016-01-04 at 14:59 -0500, Chet Ramey wrote:
>> On 1/4/16 1:30 PM, por...@narod.ru  wrote:
>>
>>> Bash Version: 4.3 Patch Level: 42 Release Status: release Description:
>>> There should be an easy way to remove the currently selected command
>>> from the history. 
>>
>>
>> Easier than `history -d'?
> 
> Look into my proposal carefully: I propose to do an equivalent of `history
> -d' with user pressing a single key.

I did; is that significantly easier, and enough in demand, to make the
implementation effort worthwhile?


-- 
``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/

Re: Feature: Easily remove current command from history

[Victor Porton]

On Mon, 2016-01-04 at 15:14 -0500, Chet Ramey wrote:
> On 1/4/16 3:09 PM, Victor Porton wrote:
> > On Mon, 2016-01-04 at 14:59 -0500, Chet Ramey wrote:
> > > On 1/4/16 1:30 PM, por...@narod.ru por...@narod.ru>
> > > wrote:
> > > 
> > > > Bash Version: 4.3 Patch Level: 42 Release Status: release
> > > > Description:
> > > > There should be an easy way to remove the currently selected
> > > > command
> > > > from the history. 
> > > 
> > > 
> > > Easier than `history -d'?
> > 
> > Look into my proposal carefully: I propose to do an equivalent of
> > `history
> > -d' with user pressing a single key.
> 
> I did; is that significantly easier, and enough in demand, to make
> the
> implementation effort worthwhile?
It is important for security:
It should be easy to remove lines with passwords and potentially
harmful commands (like sudo with rm).


-- 
Victor Porton - http://portonvictor.org

Re: Feature: Easily remove current command from history

[Piotr Grzybowski]

On Mon, Jan 4, 2016 at 9:19 PM, Victor Porton  wrote:
> It is important for security:
>
> It should be easy to remove lines with passwords and potentially harmful
> commands (like sudo with rm).

never put your passwords in plain text in commands, thats important
for security. If, for some reasons, you have to type sensitive data
inline, take any precautions available to not to put the command in
the history.

sincerely,
pg

Re: Feature: Easily remove current command from history

[Andreas Schwab]

Victor Porton  writes:

> It should be easy to remove lines with passwords and potentially
> harmful commands (like sudo with rm).

C-a C-k

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Feature: Easily remove current command from history

[Greg Wooledge]

On Mon, Jan 04, 2016 at 09:30:37PM +0100, Piotr Grzybowski wrote:
> On Mon, Jan 4, 2016 at 9:19 PM, Victor Porton  wrote:
> > It is important for security:
> >
> > It should be easy to remove lines with passwords and potentially harmful
> > commands (like sudo with rm).
> 
> never put your passwords in plain text in commands, thats important
> for security. If, for some reasons, you have to type sensitive data
> inline, take any precautions available to not to put the command in
> the history.

Such measures may include prefixing the command with a space when you
enter it, if you have ignorespace or ignoreboth in the HISTCONTROL
variable.

Re: Feature: Easily remove current command from history

[Victor Porton]

On Mon, 2016-01-04 at 15:37 -0500, Greg Wooledge wrote:
> On Mon, Jan 04, 2016 at 09:30:37PM +0100, Piotr Grzybowski wrote:
> > On Mon, Jan 4, 2016 at 9:19 PM, Victor Porton 
> > wrote:
> > > It is important for security:
> > > 
> > > It should be easy to remove lines with passwords and potentially
> > > harmful
> > > commands (like sudo with rm).
> > 
> > never put your passwords in plain text in commands, thats important
> > for security. If, for some reasons, you have to type sensitive data
> > inline, take any precautions available to not to put the command in
> > the history.
> 
> Such measures may include prefixing the command with a space when you
> enter it, if you have ignorespace or ignoreboth in the HISTCONTROL
> variable.
I know. But I sometimes forget to put a space. Also some server
accounts may be not configured for ignorespace.

-- 
Victor Porton - http://portonvictor.org

Re: Feature: Easily remove current command from history

[Eduardo A . Bustamante López]

Take into account that many options have been provided (history -d, the space
prefix, even editing .bash_history yourself).

But you request a single key stroke to do this... why?

If you enter a password by mistake in your shell, and it gets recorded, then
you go and clean up. It's not hard to do.

But since you request a simple-and-easy way of doing this, it seems like you do
this a lot... which you shouldn't! :-)

Now, it is up to you to convince Chet that it is so important to have a simple
shortcut to do this. IMO, it isn't.

-- 
Eduardo Bustamante
https://dualbus.me/

Re: Feature: Easily remove current command from history

[Dennis Williamson]

On Mon, Jan 4, 2016 at 3:07 PM, Eduardo A. Bustamante López <
dual...@gmail.com> wrote:

> Take into account that many options have been provided (history -d, the
> space
> prefix, even editing .bash_history yourself).
>
> But you request a single key stroke to do this... why?
>
> If you enter a password by mistake in your shell, and it gets recorded,
> then
> you go and clean up. It's not hard to do.
>
> But since you request a simple-and-easy way of doing this, it seems like
> you do
> this a lot... which you shouldn't! :-)
>
> Now, it is up to you to convince Chet that it is so important to have a
> simple
> shortcut to do this. IMO, it isn't.
>
> --
> Eduardo Bustamante
> https://dualbus.me/
>
>

Just bind your own keystroke to a function which uses history -d:

histdel() {
local last_command histline

last_command=$(history 1)

histline="${last_command%  *}"

history -d "$histline"#  I wish history -d accepted negative offsets
}

bind -x '"\ez": histdel'

Then Esc-z or Alt-z will delete the most recent history entry. You could
choose another keystroke to bind.


-- 
Visit serverfault.com to get your system administration questions answered.

Re: Feature: Easily remove current command from history

[Dennis Williamson]

On Mon, Jan 4, 2016 at 4:05 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:

>
>
> On Mon, Jan 4, 2016 at 3:07 PM, Eduardo A. Bustamante López <
> dual...@gmail.com> wrote:
>
>> Take into account that many options have been provided (history -d, the
>> space
>> prefix, even editing .bash_history yourself).
>>
>> But you request a single key stroke to do this... why?
>>
>> If you enter a password by mistake in your shell, and it gets recorded,
>> then
>> you go and clean up. It's not hard to do.
>>
>> But since you request a simple-and-easy way of doing this, it seems like
>> you do
>> this a lot... which you shouldn't! :-)
>>
>> Now, it is up to you to convince Chet that it is so important to have a
>> simple
>> shortcut to do this. IMO, it isn't.
>>
>> --
>> Eduardo Bustamante
>> https://dualbus.me/
>>
>>
>
> Just bind your own keystroke to a function which uses history -d:
>
> histdel() {
> local last_command histline
>
> last_command=$(history 1)
>
> histline="${last_command%  *}"
>
> history -d "$histline"#  I wish history -d accepted negative
> offsets
> }
>
> bind -x '"\ez": histdel'
>
> Then Esc-z or Alt-z will delete the most recent history entry. You could
> choose another keystroke to bind.
>
>
> --
> Visit serverfault.com to get your system administration questions
> answered.
>

Actually, this is better:

histdel() {

(#  use a subshell to make extglob setting and function variables
local

last_command=$(history 1)

#  strip modified-entry marker, it doesn't matter if we delete an
asterisk in the command since we're deleting it anyway
last_command=${last_command/\*/ }
shopt -s extglob
last_command=${last_command##*( )}  # strip leading spaces
histline="${last_command%%  *}"

history -d "$histline"#  I wish history -d accepted negative offsets

)
}

bind -x '"\ez": histdel'

I'm using a subshell here. You can use the local keyword for variables and
save and restore the extglob setting if you prefer.

-- 
Visit serverfault.com to get your system administration questions answered.