Re: odd error from bash exec binary on cmd line

[Chet Ramey]

On 3/24/18 3:31 PM, L A Walsh wrote:

> bash sleep 1
> 
> I get:
> 
> /usr/bin/sleep: /usr/bin/sleep: cannot execute binary file
> 
> ???
> Isn't it bash that cannot execute the binary file because
> it expected a script?

Think about what happens when you run a command like that. Bash sees
that it has an argument, which it assumes to be a script. It sets the
positional parameters and $0 accordingly. Posix and historical behavior
say that $0 gets set from the name of the script.

Then the shell attempts to open the file and read it. It discovers
the file is not a text file, and refuses to execute it, prefixing the
error message with $0 as it usually does.


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

Re: weird bash5 bug with ``for i; do echo; done; echo in''

[Chet Ramey]

On 3/24/18 11:24 AM, Clark Wang wrote:
> Hi Chet,
> 
> Today I compiled bash5 (using default configuration) from the devel branch
> (f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks
> one of my rc files. After some time of debugging I have the following
> minimal example to reproduce the problem:
> 
> $ bash5 -c 'for i; do echo; done; echo in'
> bash5: -c: line 0: syntax error near unexpected token `in'
> bash5: -c: line 0: `for i; do echo; done; echo in'
> $

Thanks for the report. One more case to take care of for Posix grammar
rule 6. I will fix it.

Chet

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

Re: bash long prompt, color going past the end of prompt after reaching bottom of terminal

[Chet Ramey]

On 3/23/18 12:47 PM, Musse Abdullahi wrote:
> Virta,
> 
> your workaround solves the first issue but creates another one.
> 
> Here is the script with your workaround
> 
> |calculate_prompt1(){host="my-linux"git_branch="a very very very very very
> very very very very very very very very very long prompt"prompt="@$host \\w
> : \[$(tput bold)$(tput setab 1)$(tput setaf 7)\]${git_branch}\[$(tput 
> sgr0)||$(tput el)\]\$ "export 
> PS1="$prompt"}PROMPT_COMMAND="calculate_prompt1;"
> |
> 
> |
> |
> 
> |Now keep pressing enter to the bottom of the terminal, and
> |
> 
> |you will see that the initial problem is solved. next write anything that
> flows to the next line (forcing a scroll). Then press "Home" button to go
> back to the beginning of what you wrote.
> |
> 
> |you will see that the entire line after the prompt is deleted.

I can't reproduce this with bash-4.4.19, using ^A for HOME (no HOME button
on my keyboard).

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

Re: [PATCH] fix a bug that bind -x '"\C-@": unix-command' does not work

[Chet Ramey]

On 3/20/18 12:35 PM, Koichi Murase wrote:

> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
> 
> 
> Description:
> 
>   In bash-4.3.43, bash-4.4.12, and the latest commit of the devel
> branch, `bind -x' does not work for key sequences containing `\C-@'.

Thanks for the report and patch for this. Adding a new public interface
is the right way to do it.

I'm less certain about your second set of patches. This breaks backward
compatibility -- defined as what callers have come to expect -- in
several ways.

Philosophically, there should not be that much difference between a
function that accepts a `translated' key sequence and one that doesn't.
Even if a key sequence starts in an `untranslated' state, the caller
should be able to pass the translated version to rl_translate_keyseq
and have the result unchanged. It's an unusual key binding that can't
handle this, and I believe \C-@ is the only key sequence for which it
matters. None of the arrow key sequences in common use, for example,
contain it (that is your objection with _rl_term_ku, etc.).

Since I believe that for the most part `raw' key sequences such as those
in _rl_term_ku will pass through rl_translate_keyseq without modification,
I'm going to try the changes to rl_bind_keyseq_if_unbound_in_map and the
other changes in your second patch and see how it goes.

Chet

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

Re: bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace

[Chet Ramey]

On 3/23/18 4:34 AM, Andrei Vagin wrote:
> On Thu, Mar 22, 2018 at 6:25 PM, Chet Ramey  wrote:
>> On 3/22/18 3:38 PM, Andrei Vagin wrote:
>>
>>> I am thinking how to fix this issue properly. Here are a few points:
>>> * bash should know that signals are ignored if a process is the init
>>> process in a pid namespace.
>>
>> Why should it know this? It's not documented, not portable, and conflicts
>> with the way signals are documented to behave. This is a situation-specific
>> problem.
> 
> It is "documented" in many places. For exmaple:
> https://lwn.net/Articles/532748/

I'm glad you put quotes around "documented" before referring to some
random article.


>>> * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled 
>>> differently
>>
>> Fatal signals (signals whose default disposition is to exit the process)
>> are pretty much handled identically.
> 
> Let's I try to elaborate what I mean.

Bash handles fatal signals identically. I understand that the Linux kernel
changes signal delivery behavior under certain circumstances.

>>> * bash should not return back from termsig_sighandler(), if it has
>>> sent a signal to itself.
>>
>> That suggests that the easiest way to solve the problem is to add a call
>> to exit() after the kill().
> 
> You are right with one exception. We expect that the kernel generates
> a core dump file, if a process was killed by SIGSEGV, SIGBUS, SIGFPE,
> etc.
> 
> For these signals, we probably can dereference an invalid pointer
> instead of calling exit().

If you'd like to submit a patch that does that, I'll take a look.

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