Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On 11/22/22 5:01 PM, Chet Ramey wrote: Thanks for the report. It's an easy fix; bash was optimizing away the fork and therefore not printing the timing information. Awesome! Hitting it with a hammer: $10 Knowing WHERE to hit it: $9,990 «grin» -- :- Dabe
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On 11/21/22 9:32 PM, Koichi Murase wrote: `git bisect' finds the following commit (2022-01-31) which introduced the behavior: commit b325b0e96bd05c76bbfc4d60d0707fc93d58f03f (HEAD, refs/bisect/bad) execute_cmd.c - execute_in_subshell: call optimize_subshell_command for (list) subshells to either set CMD_NO_FORK for simple commands or set CMD_TRY_OPTIMIZING for likely candidates for later optimization More crumbs, FTR: 19:51 this comment looks very suspicious https://git.savannah.gnu.org/cgit/bash.git/diff/execute_cmd.c?h=devel=9928dcb48f35d957d936f9c6d8bec8cec8b76317 19:52 that patch addresses this bug https://lists.gnu.org/archive/html/bug-bash/2021-09/msg00047.html -- :- Dabe
Re: `time ( someCmd )` Doesn't Print Time Under 5.2
On 11/21/22 7:36 PM, Emanuele Torre wrote: On Mon, Nov 21, 2022 at 07:07:08PM -0500, d...@dabe.com wrote: emanuele6 suspects it has to do with https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html No, actually later, I said that it has probably been introduced earlier since I tried running 'time (sleep 1)' in a version of bash that preceeds that change (namely 6711d2dc7793ed3d35e91b2bd4ecbdfccfcf469f (2022-10-24)), and it still didn't print the timing report. Mea culpa... Thanks for the clarification! :-D -- :- Dabe
Re: readline 'unix-filename-rubout' whitespace bug
On 8/27/21, 5:22 PM, Dabrien 'Dabe' Murphy wrote:
On 8/27/21, 4:09 PM, Chet Ramey wrote:
That circumstance is a pathname consisting solely of one or more
slashes,
separated from the previous word by whitespace. I'll fix it.
The code has been like this since January, 2004. That's pretty dated.
I guess I was just hoping somebody smarter than me [that's not hard] would
bust out some super fu and say something like, "Have you tried adding
'set word-break-chars [blah]' to your .inputrc ?" «grin»
[FWIW, I'm sure the "bug-bash" list isn't actually the right venue for
this, and I
apologize, but I figured I'd send this along as a reply, just for
posterity...]
Although the following doesn't — slash *CAN'T* ? — save to the kill ring
(it doesn't
even attempt to keep track of $READLINE_MARK), I came up with the following
"clever workaround" [read: "gross hack"] to wrangle even bash 3.2 into
submission:
prompt% less ~/.bash_readline
...
### Set up macro (shell function) to eval
unix_filename_rubout() {
local removed_space=0 removed_slash=0
while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
[[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^\ ?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT -
1))}${READLINE_LINE: $((READLINE_POINT--))}"
removed_space=1
done
while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
[[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^/?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT -
1))}${READLINE_LINE: $((READLINE_POINT--))}"
removed_slash=1
done
if ! { [[ ${removed_slash:-0} -ge 1 ]] && [[ ${removed_space:-0}
-ge 1 ]]; }; then
removed_space=0
while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
[[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^\ ?$
]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT -
1))}${READLINE_LINE: $((READLINE_POINT--))}"
removed_space=1
done
else
removed_space=0
fi
if ! { [[ ${removed_slash:-0} -ge 1 ]] && [[ ${removed_space:-0}
-ge 1 ]]; }; then
while [[ ${READLINE_POINT:-0} -gt 0 ]] &&
! [[ ${READLINE_LINE: $((READLINE_POINT - 1)): 1} =~ ^[\
/]?$ ]]; do
READLINE_LINE="${READLINE_LINE: 0: $((READLINE_POINT -
1))}${READLINE_LINE: $((READLINE_POINT--))}"
done
fi
}
stty werase undef
bind -x '"\C-w": unix_filename_rubout'
You know what they say... "If it's stupid but it works, it isn't
stupid." «grin»
Thanks! :-D
--
:- Dabe
Re: readline 'unix-filename-rubout' whitespace bug
On 8/27/21, 4:09 PM, Chet Ramey wrote: Thanks for the report. That circumstance is a pathname consisting solely of one or more slashes, separated from the previous word by whitespace. I'll fix it. Awesome! :-D PS — Another pathological test case is, e.g.: ls / / / // The code has been like this since January, 2004. That's pretty dated. For sure! I guess I was just hoping somebody smarter than me [that's not hard] would bust out some super fu and say something like, "Have you tried adding 'set word-break-chars [blah]' to your .inputrc ?" «grin» Thanks for the quick reply, -- :- Dabe
Re: shell-expand-line drops quotation marks [FIXED]
On 11/3/16, 4:21 PM, Chet Ramey wrote:
Quote Removal makes sense during command EXECUTION (since you wouldn't want
your quotes passed in with the arguments) but it doesn't make sense during
(readline) EDITING, IMHO...
OK. So let's talk about a mechanism to provide alternate behavior. The
conventional way to do that in the context of key bindings is to modify
behavior based on whether or not the user supplies a numeric argument
(e.g., M-1M-C-e).
As if Esc + Control-E wasn't already enough of a contortion! «grin»
I've actually bound `shell-expand-line` to ^X+Tab --- sort of an über
expansion, if you will... I guess one could always add Yet Another
level of indirection:
prompt% bind '"\C-x\C-i":"\e1\e\C-e"' # Ow, my brain!
At the very least, I would expect `shell-expand-line` to be more or less
idempotent; expanding the line multiple times shouldn't change the behavior
of the command that actually gets executed:
This is not a reasonable expection. Think of it as running a command
through `eval' several times.
prompt% echo $'\007'
prompt% eval eval eval eval eval echo $'\007'
(Okay, so I know you were thinking more along the lines of `eval $(eval
$(eval echo echo echo 'Hi There!') )` but I don't think anybody would
expect that to be repeatable...)
I will have to think a little bit more, however, about what I mean when
I do:
prompt% foo="one two" # two words
prompt% bar='$foo' # bare reference
prompt% baz='"$foo"'# double-quoted reference
prompt% bad=\'\$foo\' # single-quoted reference
Currently I don't like *EITHER* scenario:
old% echo $bad []
old% echo '$foo' []
old% echo $foo []
old% echo one two
new% echo $bad []
new% echo '$foo' []
new% echo 'one two'
In my mind, '$foo' would be unexpandable... Ditto:
prompt% echo \$foo # Should not change anything...
prompt% alias ls="ls -F"
prompt% ls []
prompt% ls -F []
prompt% ls -F -F []
prompt% ls -F -F -F
This is actually the correct behavior. `ls' has an alias, and that alias
is expanded.
I don't disagree that that's what it's doing, but it seems like it could
be ensmartened, somehow, to recognize when an alias would expand to
itself...
I'm also on the fence about whether I would prefer:
prompt% alias zz=yy
prompt% alias yy=xx
prompt% alias xx=ls
prompt% zz []
prompt% yy
or:
prompt% zz []
prompt% ls
THAT'S the kind of thing I'd expect a numeric prefix argument to
control: whether to recurse or not... And the logic already exists to
prevent the following circular definition from getting stuck in an
infinite loop; I would imagine it could be reused to short-circuit the
expansion, as well:
prompt% alias xx=yy
prompt% alias yy=zz
prompt% alias zz=xx
prompt% xx
-bash: xx: command not found
Nice catch. This is pretty close, and gets you most of the way you want
to go. You'd also like a way to inhibit process and command substitution
during shell-expand-line and allow those to be performed as part of
execution to avoid side effects.
Process substitution, yeah, I can't actually imagine it ever being
useful to actually SEE the "/dev/fd/##" --- any my fix actually inhibits
it already... Though after you mentioned it, I was actually kind of
surprised to see the old behavior even worked at all:
old% cat <(echo Hi There) []
old% cat /dev/fd/63 []
Hi There
COMMAND substitution, however... I could see that being useful:
prompt% echo server-$(date +%Y%m%d).log []
prompt% echo server-20161103.log
Or here's a more practical example:
prompt% vi $(grep -ri -l old_text lib/)
prompt% git add !*# WHOOPS! "old_text" doesn't match anymore
prompt% vi $(grep -ri -l old_text lib/) []
prompt% vi lib/Module/foo.c lib/Module/foo.h lib/main.c
prompt% gid add !*# OKAY
As an aside, I did not expect this:
prompt% echo server-$(date +%Y%m%d).log
server-20161103.log
prompt% echo !* []
prompt% echo server-$ ( date +%Y%m%d ) .log
-bash: syntax error near unexpected token `('
But that's not actually related to shell-expand-line, itself:
prompt% echo server-$(date +%Y%m%d).log
server-20161103.log
prompt% echo !*
-bash: syntax error near unexpected token `('
### Quotes, however, seem to make things work again...
prompt% echo "server-$(date +%Y%m%d).log"
server-20161103.log
prompt% echo !*
server-20161103.log
prompt% echo !* []
prompt% echo "server-20161103.log" # OKAY
The old behavior will remain the default for now -- it's been this way for
about 25 years, after all -- but the inhibiting-quote-removal behavior
(and probably command and process substitution as well) will be available
if the user supplies a numeric argument.
My vote would still be to provide a way to make quote preservation the
default --- e.g., a "quote-shell-expand-line" readline variable:
diff --git a/bashline.c b/bashline.c
index 759e1c5..f5b59e6 100644
--- a/bashline.c
+++ b/bashline.c
@@ -315,6 +315,9 @@ static int dabbrev_expand_active = 0;
#define
shell-expand-line drops quotation marks [FIXED]
[NOTE] Below is a message I started to write listing a whole slew of
cases where `shell-expand-line` didn't Do What I Mean.
After familiarizing myself with the source code, however, I was
pleasantly surprised to discover that there's actually a one line one
character fix for almost every case I came up with(!)
So, without further ado...
8< 8< Cut Here 8< 8<
I know this thread
is a year old, but I do have to say I agree with the OP that
`shell-expand-line`'s decision to perform Quote Removal seems to violate
the Principle of Least Astonishment...
To say `shell-expand-line` "Expand[s] the line as the shell does" seems,
shall we say, "disingenuous" --- if not an outright lie... The shell
preserves whitespace:
### Helper Function ###
prompt% argDump() { while [[ $# -gt 0 ]]; do echo "ARG: '$1'";
shift; done; }
prompt% argDump "one two three"
ARG: 'one two three'
whereas `shell-expand-line` does not.
prompt% argDump "one two three" []
prompt% argDump one two three # FAIL FIXED
ARG: 'one'
ARG: 'two'
ARG: 'three'
Quote Removal makes sense during command EXECUTION (since you wouldn't
want your quotes passed in with the arguments) but it doesn't make sense
during (readline) EDITING, IMHO...
Consider the following variable expansion:
prompt% foo="one two"
prompt% argDump $foo
ARG: 'one'
ARG: 'two'
prompt% argDump "$foo"
ARG: 'one two'
prompt% argDump $foo []
prompt% argDump one two# So far, so good, actually...
prompt% argDump "$foo" []
prompt% argDump one two# FAIL FIXED
Conversely: [This is one case I have yet to solve; I imagine it involves
a carefully placed `sh_backslash_quote_for_double_quotes()`, but I
haven't worked it out, yet...]
prompt% foo='"one two"'# Double quotes inside single quotes
prompt% echo $foo
"one two"
prompt% argDump $foo
ARG: '"one'
ARG: 'two"'# I'm happy with that...
prompt% argDump $foo []
prompt% argDump "one two"
ARG: 'one two' # ARGH!!
Command Injection, anyone?
prompt% bar='; date'
prompt% echo $bar [ ]
Wed Nov 2 15:28:29 EDT 2016# Fool me once...
prompt% echo "$bar" [ ] # Better Use Protection!
Wed Nov 2 15:28:41 EDT 2016# FAIL FIXED
At the very least, I would expect `shell-expand-line` to be more or less
idempotent; expanding the line multiple times shouldn't change the
behavior of the command that actually gets executed:
prompt% echo $'\007'
# Generates ^G (BEL)
prompt% echo $'\007' [ ]
# Becomes...
prompt% echo $\007
prompt% echo $007
prompt% echo -bash07 # WTF??! How'd $0 get in there? FIXED
Ditto history expansion:
prompt% echo $'\007'
prompt% echo !$ []
prompt% echo $\007# FAIL FIXED
$007
I understand it's hard to do the Right Thing sometimes: [Still unsolved]
prompt% alias ls="ls -F"
prompt% ls []
prompt% ls -F []
prompt% ls -F -F []
prompt% ls -F -F -F
...
I thought that maybe prepending "command" or "\" might help, but you'd
still have:
prompt% alias ls="ls -F"
prompt% alias qq="ls"
prompt% qq /bin/bash
/bin/bash*# with '*', good
prompt% alias qq="\ls"# Note the backslash
prompt% qq /bin/bash
/bin/bash # zero '*', also good
prompt% qq /bin/bash []
prompt% ls /bin/bash
/bin/bash*# WITH '*'... BAD :-( FIXED
(It's worth noting that the shell itself is smart enough to figure out
when to stop expanding aliases; it seems like that logic would be useful
here, as well...)
And lastly, even when you ARE doing something "correctly", you *STILL*
have to watch out for pitfalls:
prompt% alias su='sudo -sEp '\''[sudo] password for %p: '\'''
prompt% su
[sudo] password for dabe:
prompt% su []
prompt% sudo -sEp [sudo] password for %p:# FAIL FIXED
[sudo]
/bin/bash: password: command not found
So what's the fix, you might ask?
diff --git a/bashline.c b/bashline.c
index 238a190..e17a49d 100644
--- a/bashline.c
+++ b/bashline.c
@@ -2689,7 +2689,7 @@ shell_expand_line (count, ignore)
/* If there is variable expansion to perform, do that as a separate
operation to be undone. */
new_line = savestring (rl_line_buffer);
- expanded_string = expand_string (new_line, 0);
+ expanded_string = expand_string (new_line, 1);
FREE (new_line);
if (expanded_string == 0)
{
If you're really concerned that people are actually relying on the old
behavior, I'm sure it would be easy to create some sort of
"shell-expand-preserve-quotes" readline variable, or some such... Show
me where to submit a Pull Request and I'd be happy to whip one up!
Re: "su -m" (on Mac) preserves $HOME and $USER but not ~
On 10/29/15, 4:00 PM, Greg Wooledge wrote:
Do you have a PROMPT_COMMAND variable? Or something unusual in your
PS1 variable? (Doesn't look it from the copy/paste, but you never
know.) Or do you have a DEBUG trap?
Oh yeah, I definitely make extensive use of the PROMPT_COMMAND; that's
how I stick the `date` in there. [See below...]
I can see how that could result in, shall we say, "asynchronous"
activity, but it's still a little astonishing that it would update '~'
--- especially without updating $HOME at the same time.
PS: This was cobbled together a long time ago, so try not to laugh TOO
hard at the mix of old-school "/bin/sh"-isms... ;-)
# (grep -c)
function gc {
local line arg="$1" counter=0
while read line; do
[ "$line" != "${line##*$arg}" ] && counter=$(($counter+1))
done
echo $counter
}
export WHOAMI="`whoami`"
export TTY="`tty 2>/dev/null`"
if [ ! "$TTY" = "" ]; then
export TTY_OWNER="`ls -Ll \"$TTY\" 2>/dev/null | awk '{print \$3}'`"
fij
if [ "$PS1" != "" ]; then
PROMPT_COMMAND='set_prompt'
function set_prompt () {
local numjobs=`jobs | gc Stopped`
if [ "$numjobs" = 0 ]; then
unset JOBFLAG
else
JOBFLAG="{$numjobs} "
fi
if [ "$WHOAMI" = root ]; then
prompt="# "
other=" (#)"
color="^[[31;1m"
else
prompt="> "
if [ ! "$WHOAMI" = "$TTY_OWNER" ]; then
other=" ($WHOAMI)"
color="^[[36;1m"
else
other=""
color="^[[0;1m"
fi
fi
PS1=
[ ! "$STY" = "" ] && PS1="[$STY] "
# ^[]1 = iTerm.app "tab"
# ^[]2 = konsole "tab" and taskbar app name
# ^[]30 = I forget...
if [ ! "${TERM##xterm}" = "$TERM" ] || [ ! "${TERM##screen}" =
"$TERM" ]; then
local datestr=$(date +"%a %b %d %T")
local standout_on=$(tput smso)
local standout_off=$(tput rmso)
PS1="\[^[]2;$JOBFLAG\u@\h
\W^G^[]1;\h$other^G^[]30;\h$other^G$color$standout_on\]$datestr\[$standout_off\]
$JOBFLAG${PS1}\u@\h:\w${prompt}\[^[[0m\]"
else
PS1="\[$color$standout_on\]$datestr\[$standout_off\]
$JOBFLAG${PS1}\u@\h:\w${prompt}\[^[[0m\]"
fi
echo -n $(tput cup $(tput lines) 0)
}
fi
--
:- Dabe
Re: edit-and-execute-command; minus the execute part?
On Tue, 24 Aug 2010, Dennis Williamson wrote: On 8/23/10 3:17 PM, Dabrien 'Dabe' Murphy wrote: I'd prefer it if, after exiting my $EDITOR, bash simply stuffed the results back into my readline buffer. Particularly, if I decide to abandon my changes, I find it worrisome that the shell goes ahead and executes the previous command anyway. (I guess I've grown accustomed to SVN's behavior, for example, where if you don't make any changes to your commit message, it gives you the option to abort the entire transaction.) One workaround would be to bind the keystroke to a macro that inserts a comment character at the beginning of the line before doing edit-and-execute-command. Then when you exit the editor the comment will be executed then you can press up arrow to retrieve the line and delete the comment character and do further editing then execute it. Clever. It's not /exactly/ what I had in mind, but it certainly addresses the issue at hand... (Thus making it, like you say, a workaround, hehe.) Thanks, Dennis! -- :- Dabe -- :- *Dabrien Dabe Murphy* :- /Sr. Solutions Engineer/ :- /Linux / Unix / Mac / Perl/ -- :- /Swing Dance DJ Instruction/ :- /Jitterbug, Lindy Hop, Big Band and More! /-- :- www.Dabe.com
edit-and-execute-command; minus the execute part?
Is it possible to C-xC-e /without/ immediately executing the resulting command? To my mind, editing the buffer and executing it are two different things -- the latter having potentially dire consequences... I'd prefer it if, after exiting my $EDITOR, bash simply stuffed the results back into my readline buffer. Particularly, if I decide to abandon my changes, I find it worrisome that the shell goes ahead and executes the previous command anyway. (I guess I've grown accustomed to SVN's behavior, for example, where if you don't make any changes to your commit message, it gives you the option to abort the entire transaction.) Cheers! -- :- Dabe
