Chet Ramey wrote:
The double problem is that tab is no longer bound to anything
when you leave posix -- you don't get your original completion
char back, and TAB isn't activated as a new completion character,
so completion gets disabled. Surely that can't be desirable?
(i.e. despite how bash g
On 8/4/14, 2:27 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>>>
>>>Then go back -- the TAB key is unmapped as a completion char,
>>> but your old completion key is not remapped. So you end up with
>>> no completion keys. There are probably lots of other
>>> "one-way-adjustments",
>>> but
On 8/2/14, 7:27 PM, EmanueL Czirai wrote:
> Repeat-By:
> 1. start a bash shell
> 2. put this in .bashrc
>
> PS1='$(date)\
> '
>
> put no spaces after \
> the entire thing is 2 lines - may add new line after ' though, and prior to
> PS1
>
> 3. start a new bash
> the error is:
> bash: command su
Chet Ramey wrote:
Then go back -- the TAB key is unmapped as a completion char,
but your old completion key is not remapped. So you end up with
no completion keys. There are probably lots of other "one-way-adjustments",
but I haven't hit them all.
I'm going to guess that this is the sam
On 8/1/14, 5:44 PM, Linda Walsh wrote:
> Greg Wooledge wrote:
>> On Thu, Jul 31, 2014 at 11:40:18PM -0700, Linda Walsh wrote:
>>
>>> Ishtar:/> ll {,/usr}/bin/echo
>>> -rw-r--r-- 2 136753 Nov 19 2013 /bin/echo
>>> --w--- 2 136753 Nov 19 2013 /usr/bin/echo
>>>
sudo chmod +x /bin/echo
On 8/2/14, 10:06 PM, Aaron Lewis wrote:
> Hi,
>
> I'm modifying bash source code and going to add some default variables:
>
> But I only found "set_if_not", e.g
> set_if_not ("EDITOR", "nano");
>
> How can I override that variable if it exists?
Since you're already looking through the bash sour
On 8/3/14, 11:02 AM, Tim Friske wrote:
> Hi,
>
> my assumption was that Bash's "printf" builtin implicitly defines a local
> variable when used inside a function like so:
>
> function foobar { printf -v foo bar; }
> foobar
> declare -p foo
> # Prints "bar" from the global "foo" va
On 8/4/14, 4:57 AM, Ondrej Oprala wrote:
> Hi, based on the core dump from [1], need_here_doc seems to
> attain the value of -1 under some conditions, thus passing
> "if (need_here_doc)" clauses, in this case resulting in a segfault.
Original:
http://lists.gnu.org/archive/html/bug-bash/2014-06/ms
Hi, based on the core dump from [1], need_here_doc seems to
attain the value of -1 under some conditions, thus passing
"if (need_here_doc)" clauses, in this case resulting in a segfault.
A very simple patch is attached.
Thanks,
Ondrej
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1087010
From
