On 2019/11/25 12:02, Chet Ramey wrote:
> On 11/24/19 7:35 AM, Ulrich Mueller wrote:
>> Description:
>> In a non-interactive non-posix-mode shell, saving the output of
>> "shopt -p -o" and restoring it will unset the expand_aliases option.
>>
>
> It seems like setting posix mode when it's alrea
Clint,
My thoughts on man page changes are near identical to yours. And I
thought wiser minds might first try their hand, as I do not know the
conventions the authors have used. I like how it's done now. And
something might be done a little better, I agree. So, here is my
thought. Pardon the
On 2019/11/25 07:05, wrote:
> # As you see, now everything works as expected i.e. the issue seems
> # to be in the way readline is handling multibyte invisible characters
> # in a prompt, *probably* in the rl_redisplay() function.
>
Multi-byte or not, invisible characters need to
> On 2019 Nov 25 , at 4:43 p, Peter Benjamin wrote:
>
>
> Description:
> 'in' is a builtin command and is not listed in the man page as such.
>
> Repeat-By:
>
> type at the bash command line:
>
> $ in
> bash: syntax error near unexpected token `in'
This should be a big hint that it is *no
> On Mon, 25 Nov 2019, Chet Ramey wrote:
> On 11/24/19 7:35 AM, Ulrich Mueller wrote:
>> Description:
>> In a non-interactive non-posix-mode shell, saving the output of
>> "shopt -p -o" and restoring it will unset the expand_aliases option.
> It seems like setting posix mode when it's already
Date:Mon, 25 Nov 2019 16:47:23 +0200
From:IFo Hancroft
Message-ID:
| I don't remember it on top of my head but IIRC it doesn't change the title.
In an xterm (maybe other things, sine many of them copied) \e]2; ...
sets the title. I do it that way in my (farily
Date:Mon, 25 Nov 2019 13:43:41 -0800
From:Peter Benjamin
Message-ID:
<4dc457e0135603025cd500acdc95db53f9d30482.ca...@peterbenjamin.com>
| Description:
| 'in' is a builtin command and is not listed in the man page as such.
Others have indicated what it is, but j
On 11/25/19 4:53 PM, Greg Wooledge wrote:
> On Mon, Nov 25, 2019 at 01:43:41PM -0800, Peter Benjamin wrote:
>> Description:
>> 'in' is a builtin command and is not listed in the man page as such.
>
> It's actually a keyword. It's part of the "for" and "case" syntax.
>
> wooledg:~$ type in
> in
On Mon, 25 Nov 2019, Peter Benjamin wrote:
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=
On Mon, Nov 25, 2019 at 01:43:41PM -0800, Peter Benjamin wrote:
> Description:
> 'in' is a builtin command and is not listed in the man page as such.
It's actually a keyword. It's part of the "for" and "case" syntax.
wooledg:~$ type in
in is a shell keyword
for NAME in WORDS; do ...; done
cas
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
On 11/24/19 7:35 AM, Ulrich Mueller wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -march=native -ggdb -O2 -pipe -Wno-parentheses
-Wno-format-security
uname output: Linux themis 4.14.1
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-REtn6r/bash-
5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux sid-readline 4.19.0-6-amd64 #
On 11/23/19 9:38 PM, Dennis Clarke wrote:
Nothing new .. merely pointing out this is still an issue and for even
more fun an out of tree build reveals :
/opt/bw/gcc9/bin/gcc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-pc-linux-gnu"'
-D
I need to remember that if I just hit reply, I'm not actually sending
the reply to the mailing list.
The most obvious one would be someone who doesn't want their terminal's
title bar (or whatever "7" controls) to be altered.
I don't remember it on top of my head but IIRC it doesn't change the
On Mon, Nov 25, 2019 at 04:33:13PM +0200, IFo Hancroft wrote:
> > You can do it yourself, by putting the functions I just gave you into
> > your ~/.bashrc file. This kind of change doesn't belong in the shell
> > itself, because it will *not* be a "clean solution" for everybody.
> >
> I know I ca
On 11/25/19 9:21 AM, Siteshwar Vashisht wrote:
It's an interesting question. You want $_ to expand to the last argument
(or last word) of the previous history entry when the shell is interactive,
which is available as !$, instead of the last command executed by the
current shell instance.
Shoul
- Original Message -
> From: "L A Walsh"
> To: "chet ramey"
> Cc: bug-bash@gnu.org, "Siteshwar Vashisht"
> Sent: Wednesday, April 4, 2018 2:03:05 AM
> Subject: Re: What should be the expected behavior for $_ ?
>
>
>
> Chet Ramey wrote:
> > On 4/3/18 10:03 AM, Siteshwar Vashisht wro
On Mon, Nov 25, 2019 at 02:08:04PM +0200, IFo Hancroft wrote:
> I have the following feature request:
>
> Output/send \033]7;file:///the/current/dir\033\\ on directory change.
cd() {
builtin cd "$@" &&
printf '\e]7;file://%s\a' "$PWD"
}
pushd() {
builtin pushd "$@" &&
printf '\e]
Hi Everyone!
I have the following feature request:
Output/send \033]7;file:///the/current/dir\033\\ on directory change.
This can then be used by terminals for example for the feature to be
able to open a new tab/terminal in the same directory.
Currently, the way to do it is to use the PROMPT
20 matches
Mail list logo
