Thanks for that.
It is certainly confusing that you can do "alias -p" inside the
compound statement and have it print out the alias you think you have
defined, but not have it work. But given that bit of the manual, I can
see why that would be.
On Sat, 2024-10-12 at 15:18 -0400, Chet Ramey wro
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_A
that would give you a backtrace to send with your bug report.
Aye, I put the same bug report into the bash-completion GitHub and the
backtrace is there:
https://github.com/scop/bash-completion/issues/704
--
| Ian! D. Allen, BA-Psych, MMath-CompSci idal...@idallen.ca Ottawa CANADA
| Home: ww
two completions are garbage.
# The file name is being split on newlines.
--
| Ian! D. Allen, BA-Psych, MMath-CompSci idal...@idallen.ca Ottawa CANADA
| Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca
| Former college professor of Free/Libre GNU+Linux @ teaching.i
>
> "Utilities other than the special built-ins (see Special Built-In
> Utilities) shall be invoked in a separate environment that consists of the
> following...[includes redirections specified to the utility]...The
> environment of the shell process shall not be changed by the utility"
>
>
> http:
On Wed, Apr 24, 2019, 07:12 Chet Ramey wrote:
> On 4/24/19 8:47 AM, Ian Neal wrote:
>
> > At what point is a subshell being invoked? There's no pipeline, command
> > substitution, coprocess, background process, or explicit () subshell
> here,
> > which are the
> Date:Tue, 23 Apr 2019 15:49:18 -0600
> From: Ian Neal
> Message-ID: 1_z7uy+7rv...@mail.gmail.com>
>
> | When using arithmetic expansion with variable pre- and
> | post-increments/decrements in the output redirection file path,
> |
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -
On Tue, Sep 27, 2016, at 11:08 AM, Chet Ramey wrote:
>
> Thanks for the report. There should be something in there about `.'
> and `..' always having to be matched explicitly.
Yw. I noticed another improvement that could be made to the
docs. How do you prefer patches? And, I assume you manually
On Tue, Sep 27, 2016, at 09:41 AM, L. A. Walsh wrote:
>
>
> Ian Kelling wrote:
> > The docs currently say:
> >
> > "When a pattern is used for filename expansion, the character '.' at
> > the start of a filename or immediately following a slash
shell option 'dotglob' is set and the file is not named '.'
or '..'.
And dotglob's dedicated section has similar wording to change.
I looked at making a patch, but it seems the docs are repeated in
many formats, so I figured I'd just post this first.
--
Ian Kelling
https://iankelling.org
So it is
too late to change the default.)
Signed-off-by: Ian Jackson
Signed-off-by: Ian Jackson
CC: Ian Campbell
---
MANIFEST| 3 +++
builtins/shopt.def | 2 ++
doc/bash.1 | 10 ++
doc/bashref.texi| 13 -
execute_cmd.c
Ian Jackson writes ("Re: Want way to run background processes with SIGINT
unignored"):
> Chet Ramey writes ("Re: Want way to run background processes with SIGINT
> unignored"):
> > This is the behavior that any new option would toggle. Some name like
> > `a
Chet Ramey writes ("Re: Want way to run background processes with SIGINT
unignored"):
> On 10/9/15 2:42 PM, Ian Jackson wrote:
> > However, it would be very easy for bash to provide an option (via `set
> > -o' perhaps) to disable this behaviour. That is, to al
QUIT.
This whole discussion, and these proposed options, are relevant only
when job control is not in effect.
Thanks,
Ian.
[1]
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01208.html
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01211.html
y code, but that would be
a shortcoming in the recognition of the circumstances, not a lack of
clarity in what the circumstances are.
In short, it's still a bug.
One might mitigate the bug by refusing to add the CR if output is not
a TTY. That would refrain from creating what look like DOS-f
Chet Ramey writes ("Re: Shellshock-vulnerable version still most obvious on
ftp.gnu.org"):
> On 11/6/14, 7:47 AM, Ian Jackson wrote:
> > But in the current environment it's looking rather quaint. We could
> > probably provide a full tarball for each patch release.
&
s looking rather quaint. We could
probably provide a full tarball for each patch release.
Ian.
-patches/
This is not mentioned on the main bash webpage here:
http://www.gnu.org/software/bash/
Could there please be a new full tarball release of the patched
version ?
Thanks,
Ian.
The pathexp-globignore-delim.patch seems to work as advertised.
> If *a matches scratch/a, for
> example, that's a bug in the matching code I will have to identify and fix.
Yes, this is the case. Based on your reply, the examples I showed are
definitely a bug.
Thank you so much.
Chet Ramey writes:
> On 6/9/14, 3:42 PM, Ian Kelling wrote:
> Yes, it's an interesting question: what exactly does pattern negation
> include? You can match all filenames beginning with a `.' by using `.'
> as the first character of the pattern, so should a negated
Running this script with your own bash path demonstrates the bug.
#!/home/ian/opt/bash/bash --norc
shopt -s extglob
shopt -s dotglob
cd $(mktemp -d)
mkdir a
touch a/.b
touch a/c
echo a/!(.b)
output:
a/. a/.. a/c
this happens with all bash versions 4.3+ (latest is patch 18).
before that, the
be a good feature to give vi-mode access to
the the stack of yanks from the default emacs mode. I figured it could
be called vi_yank_pop. This is a patch I wrote a long time ago. I don't
know if it works, and it probably mostly copies the emacs code.
Cheers,
Ian Kelling
--- ../bash-4.0/lib/
efore the high numbered file
descriptor created temporarily for the fifo could be closed. There's
probably a perfectly reasonable case where the process substitution
fifo on the RHS of an IO redirection operator should not be closed.
Cheers,
Ian
ay, certainly
not a digit.
Basically, by mixing IO redirection and process substitution I'm left
with a trailing file descriptor which can cause scripts to hang around
despite any subsequent redirection of stdout/stderr best practices.
There's no mechanism to discover these new file descriptors and they
are not closed on exec.
Is there any hope for me?
Cheers,
Ian
consistent.
- Ian Kelling
Chet Ramey wrote:
Ian Kelling wrote:
Special Sauce wrote:
From: anton
To: bug-bash@gnu.org
Subject: Cursor starts inside prompt
I just noticed this issue too. It seems it was fine under gnu screen,
but not with plain xterm or gnome-terminal. Upgrading to the latest
patch version 4.0.17 fixed
Chet Ramey wrote:
> Ian Kelling wrote:
>> Special Sauce wrote:
>>> From: anton
>>> To: bug-bash@gnu.org
>>> Subject: Cursor starts inside prompt
>> I just noticed this issue too. It seems it was fine under gnu screen,
>> but not with plain xterm or
Special Sauce wrote:
From: anton
To: bug-bash@gnu.org
Subject: Cursor starts inside prompt
I just noticed this issue too. It seems it was fine under gnu screen, but not
with plain xterm or gnome-terminal. Upgrading to the latest patch version
4.0.17 fixed it.
- Ian Kelling
Chet Ramey wrote:
I cannot reproduce this using bash-4.0.10 or bash-4.0.17 on Mac OS X,
Ubuntu, RHEL 4, or FreeBSD.
Chet
I can't reproduce it either.
- Ian Kelling
Jared Yanovich wrote:
Hi, I upgraded to bash 4.0.10 and my PS1 prompt is no longer displaying
anything at all.
I think this was addressed in a recent patch. Try upgrading to the most recent
version.
- Ian Kelling
something else going on in your invocation files. Try making
that the only line in your .bashrc and starting a non-login shell so thats the
only file read.
- Ian Kelling
;ve got to
track down everything in your invocation files that affects your prompt and
narrow it down to something we can test ourselves.
- Ian Kelling
-m does not apply to parent directories created with -p
If you wanted to deal with the -p, I would remove it and not pass it to mkdir,
but create them yourself in the function. I'd use parameter expansion to deal
with parts of the path 1 by 1.
- Ian Kelling
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='b
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler:
/bind/obj/repos/dist-buildroot.hg/build_x86_64/staging_dir/usr/bin/x86_64-linux-uclibc-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MA
releasing 3.1?
Cheers,
Ian
--
Ian Macdonald | Once harm has been done, even a fool
[EMAIL PROTECTED] | understands it. -- Homer
http://www.caliban.org/ |
|
|
__
s second invocation, the alias was not used as it
should have been.
Ian
--
Ian Macdonald | I sometimes think that God, in creating
[EMAIL PROTECTED] | man, somewhat overestimated his ability.
http://www.cal
Hello,
I can't quite work out what the difference is between -o default and -o
bashdefault. One is readline-oriented and the other is not, but the
effect appears to be the same for the cases that I have run through.
Anyone?
Ian
--
Ian Macdonald | The one good thing
On Thu 07 Jul 2005 at 20:07:33 -0400, you wrote:
> On Thu, 7 Jul 2005, Ian Macdonald wrote:
>
> >Hello,
> >This doesn't seem right:
> >[EMAIL PROTECTED] bash_completion]$ foo=x
> >[EMAIL PROTECTED] bash_completion]$ foo=bar
> >[EMAIL PROTECTED] bash_comp
oo=bar 2>/dev/null
bash: foo: readonly variable
[EMAIL PROTECTED] bash_completion]$ foo=bar &>/dev/null
bash: foo: readonly variable
[EMAIL PROTECTED] bash_completion]$ bash --version
GNU bash, version 3.00.16(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation,
41 matches
Mail list logo
