Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

This issue came up in the following help-bash thread:
http://lists.gnu.org/archive/html/help-bash/2017-05/msg1.html

Write:  then hit return. Bash will output the secondary
prompt, because it expects the user to close the single quote. Run
`edit-and-execute-command' to fix the input (e.g. ). Bash
will then execute the command, but it'll output the secondary prompt
again, expecting the user to close the single quote.

bash-4.4$ echo '
>
echo 'x'
x
>
Program received signal SIGINT, Interrupt.
0x776ee2b1 in __pselect (nfds=1, readfds=0x7fffccb8,
writefds=0x0, exceptfds=0x0, timeout=,
sigmask=0x8101f8 <_rl_orig_sigset>) at
../sysdeps/unix/sysv/linux/pselect.c:69
69  ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.

(gdb) bt
#0  0x776ee2b1 in __pselect (nfds=1, readfds=0x7fffccb8,
writefds=0x0, exceptfds=0x0, timeout=,
sigmask=0x8101f8 <_rl_orig_sigset>) at
../sysdeps/unix/sysv/linux/pselect.c:69
#1  0x00520e32 in rl_getc (stream=0x779a58c0
<_IO_2_1_stdin_>) at input.c:515
#2  0x005217cb in rl_read_key () at input.c:481
#3  0x004fe038 in readline_internal_char () at readline.c:570
#4  0x004ff7c2 in readline_internal_charloop () at readline.c:656
#5  0x004fdb32 in readline_internal () at readline.c:670
#6  0x004fd9f0 in readline (prompt=0x88d6e8 "> ") at readline.c:374
#7  0x0042cb08 in yy_readline_get () at ./parse.y:1464
#8  0x0042cc59 in yy_readline_get () at ./parse.y:1495
#9  0x00431aab in yy_getc () at ./parse.y:1397
#10 0x00432348 in shell_getc (remove_quoted_newline=0) at ./parse.y:2297
#11 0x00436708 in parse_matched_pair (qc=39, open=39,
close=39, lenp=0x7fffd164, flags=0) at ./parse.y:3430
#12 0x00433215 in read_token_word (character=39) at ./parse.y:4857
#13 0x00431768 in read_token (command=0) at ./parse.y:3338
#14 0x0042c16e in yylex () at ./parse.y:2683
#15 0x00428abe in yyparse () at y.tab.c:1821
#16 0x004285ab in parse_command () at eval.c:294
#17 0x00428392 in read_command () at eval.c:338
#18 0x00428091 in reader_loop () at eval.c:140
#19 0x004253bb in main (argc=1, argv=0x7fffe498,
env=0x7fffe4a8) at shell.c:794

Bash is still in `parse_matched_pair'-

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 7:42 AM, Eduardo Bustamante  wrote:
[...]
> Bash is still in `parse_matched_pair'-

This *seems* to fix it, but I actually have no clue if this is
correct, or if more cleanup is required prior to the longjmp. I also
removed `rl_forced_update_display ()', because otherwise Bash will
display an awkward PS2 just before displaying PS1 again.

dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
diff --git a/bashline.c b/bashline.c
index 7884416a..1b59af91 100644
--- a/bashline.c
+++ b/bashline.c
@@ -937,7 +937,6 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)
 {
   char *command, *metaval;
   int r, rrs, metaflag;
-  sh_parser_state_t ps;

   rrs = rl_readline_state;
   saved_command_line_count = current_command_line_count;
@@ -973,9 +972,7 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)

   if (rl_deprep_term_function)
 (*rl_deprep_term_function) ();
-  save_parser_state (&ps);
   r = parse_and_execute (command, (editing_mode == VI_EDITING_MODE) ?
"v" : "C-xC-e", SEVAL_NOHIST);
-  restore_parser_state (&ps);
   if (rl_prep_term_function)
 (*rl_prep_term_function) (metaflag);

@@ -989,7 +986,7 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)
   rl_done = 0;
   rl_readline_state = rrs;

-  rl_forced_update_display ();
+  jump_to_top_level (DISCARD);

   return r;
 }

unalias works weirdly inside an if-then block

[Gabor Burjan]

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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/sha$
uname output: Linux hostname 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31
14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.4
Patch Level: 0
Release Status: release

Description:
unalias works weirdly inside an if-then block

Repeat-By:
By sourcing the code below in an interactive shell

I can reproduce the bug on vanilla 4.4 version,
on 4.3.46 (Ubuntu 16.04 default) and
on 4.2.46 (RHEL 7.1 default)

# Small code snippet to reproduce weird unalias functionality
# Call with "source scriptname" in a fresh *interactive* shell

touch /tmp/a /tmp/b
alias cp='cp -i'

if [[ 1 = 1 ]]; then

echo -n 'before unalias: '
alias | grep '^alias cp='
echo -e "(end of alias output)\n"

unalias cp
echo -n 'after unalias: '
alias | grep '^alias cp='
echo -e "(end of alias output)\n"

set -x
# This one will be interactive, but why?
cp /tmp/a /tmp/b
fi

# This one won't be interactive
cp /tmp/a /tmp/b
set +x

Re: unalias works weirdly inside an if-then block

[Eduardo Bustamante]

On Fri, May 12, 2017 at 7:33 AM, Gabor Burjan  wrote:
[...]
> Description:
> unalias works weirdly inside an if-then block

It's not just an if-then block. It's any kind of block:

 dualbus@debian:~$ bash alias
 + shopt -s expand_aliases
 + alias 'x=echo x'
 + echo x
 x
 + unalias x
 + echo x
 x
 + x
 alias: line 9: x: command not found

 dualbus@debian:~$ cat alias
 set -x
 shopt -s expand_aliases
 alias x='echo x'
 x
 {
  unalias x
  x
 }
 x

This is explained in the ALIASES section of the bash manual:

| The rules concerning the definition and use of aliases are somewhat
confusing.  Bash always reads  at  least  one  complete
| line  of input before executing any of the commands on that line.
Aliases are expanded when a command is read, not when it
| is executed.  Therefore, an alias definition appearing on the same
line as another command does not take effect  until  the
| next  line  of  input is read.  The commands following the alias
definition on that line are not affected by the new alias.
| This behavior is also an issue when functions are executed.  Aliases
are expanded when a function definition is  read,  not
| when  the  function is executed, because a function definition is
itself a command.  As a consequence, aliases defined in a
| function are not available until after that function is executed.
To be safe, always put alias definitions on  a  separate
| line, and do not use alias in compound commands.

(the key part here is that aliases are expanded when a command is
read, not when it's executed. Bash needs to parse the whole block, at
which point the alias is expanded. The unalias is not executed but
until after).

Re: unalias works weirdly inside an if-then block

[Greg Wooledge]

On Fri, May 12, 2017 at 02:33:06PM +0200, Gabor Burjan wrote:
>   unalias works weirdly inside an if-then block

Because bash has to parse the entire compound command (the entire
multi-line command up to "fi") before it can begin execution of it.

> alias cp='cp -i'
> 
> if [[ 1 = 1 ]]; then
> unalias cp
> cp /tmp/a /tmp/b
> fi

Bash reads the entire if...fi command, parses it (which includes expansion
of the alias), and then begins executing it.  The cp command has already
been replaced by cp -i.

> # This one won't be interactive
> cp /tmp/a /tmp/b

This command isn't read/parsed until after the "unalias" has already
executed.

There is a similar issue with "shopt -s extglob".  Attempting to use it
to change the parser while inside a compound command (e.g. a function)
does not work the way people expect.

Commands that change the parser (alias, unalias, shopt -s extglob) must
be executed at the top of the script, outside of any functions, and
should be in effect for the entire script.  Attempting to toggle the
parser between states on the fly is a really bad idea.

Re: unalias works weirdly inside an if-then block

[Gabor Burjan]

On Fri, May 12, 2017 at 08:11:35AM -0500, Eduardo Bustamante wrote:
> On Fri, May 12, 2017 at 7:33 AM, Gabor Burjan  wrote:
> [...]
> > Description:
> > unalias works weirdly inside an if-then block
> 
> It's not just an if-then block. It's any kind of block:
> [...]
> 
> (the key part here is that aliases are expanded when a command is
> read, not when it's executed. Bash needs to parse the whole block, at
> which point the alias is expanded. The unalias is not executed but
> until after).

In this case it's not a bug, but the documented behaviour.
Thanks for the explanation.

BR,
Gabor

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Chet Ramey]

On 5/12/17 8:42 AM, Eduardo Bustamante wrote:
> This issue came up in the following help-bash thread:
> http://lists.gnu.org/archive/html/help-bash/2017-05/msg1.html
> 
> Write:  then hit return. Bash will output the secondary
> prompt, because it expects the user to close the single quote. Run
> `edit-and-execute-command' to fix the input (e.g. ). Bash
> will then execute the command, but it'll output the secondary prompt
> again, expecting the user to close the single quote.

It's meant to work like that, and always has.

The command is executed in a separate context, exactly the same as
running fc on a command from the history file (in fact, that's what
happens).  It's meant to not affect the contents of the current
command line. That's how Posix specifies it.

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

Re: Compiling bash statically in 4.2/4.3/4.4 with GCC 6.1.0

[Eduardo Bustamante]

FWIW, I'm able to compile bash statically with:

dualbus@debian:~/src/gnu/bash$ ./configure --enable-static-link
--without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make
[...]
dualbus@debian:~/src/gnu/bash$ file bash
bash: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
BuildID[sha1]=183cd0733ecc4aae4d60226fd419c616cfcc5f57, not stripped
dualbus@debian:~/src/gnu/bash$ ./bash --version
GNU bash, version 4.4.12(2)-maint (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

In my system (Debian), libc.a is provided by libc6-dev:

dualbus@debian:~/src/gnu/bash$ dpkg -S /usr/lib/x86_64-linux-gnu/libc.a
libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a

dualbus@debian:~/src/gnu/bash$ gcc --version
gcc (Debian 6.3.0-16) 6.3.0 20170425
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


It fails if I try to use clang though:

dualbus@debian:~/src/gnu/bash$ CC=clang ./configure
--enable-static-link --without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make
bison -y -d ./parse.y
./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
touch parser-built
rm -f mksyntax
clang -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"linux-gnu"'
-DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"' -DCONF_VENDOR='"unknown"'
-DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I.  -I. -I./include -I./lib
-g -O2 -Wno-parentheses -Wno-format-security   -rdynamic -g -O2
-Wno-parentheses -Wno-format-security  -static -rdynamic -g -O2
-Wno-parentheses -Wno-format-security  -o mksyntax ./mksyntax.c
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer
equality in 
`/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/libc.a(strcmp.o)'
can not be used when making an executable; recompile with -fPIE and
relink with -pie
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:702: recipe for target 'mksyntax' failed
make: *** [mksyntax] Error 1

dualbus@debian:~/src/gnu/bash$ clang --version
clang version 3.8.1-23 (tags/RELEASE_381/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

It seems to be caused by the combination of `-static' and `rdynamic'
(from LOCAL_LDFLAGS). This "works" though:

dualbus@debian:~/src/gnu/bash$ CC=clang ./configure
--enable-static-link --without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make LOCAL_LDFLAGS=
[...]
dualbus@debian:~/src/gnu/bash$ file ./bash
./bash: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
BuildID[sha1]=26ee2a8080868b2923e21f3c17c6814ae30905fb, not stripped
dualbus@debian:~/src/gnu/bash$ ./bash --version
GNU bash, version 4.4.12(1)-maint (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 8:35 AM, Chet Ramey  wrote:
[...]
> The command is executed in a separate context, exactly the same as
> running fc on a command from the history file (in fact, that's what
> happens).  It's meant to not affect the contents of the current
> command line. That's how Posix specifies it.

Hm, I'm reading:

1. 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_03
"Command Line Editing (vi-mode)"
2. 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_05
"vi Line Editing Command Mode"
3. And http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html

I find:

(from 2, i.e. command mode)
| [number]v
| Invoke the vi editor to edit the current command line in a temporary
file. When
| the editor exits, the commands in the temporary file shall be executed and
| placed in the command history. If a number is included, it specifies the
| command number in the command history to be edited, rather than the current
| command line.

(from 1, i.e. vi-mode)
| If sh receives a SIGINT signal in command mode (whether generated by
typing the
| interrupt character or by other means), it shall terminate command
line editing
| on the current command line, reissue the prompt on the next line of the
| terminal, and reset the command history (see fc) so that the most recently
| executed command is the previous command (that is, the command that was being
| edited when it was interrupted is not re-entered into the history).

(from 3, i.e fc)
| -e  editor
| Use the editor named by editor to edit the commands. The editor string is a
| utility name, subject to search via the PATH variable (see XBD Environment
| Variables). The value in the FCEDIT variable shall be used as a
default when -e
| is not specified. If FCEDIT is null or unset, ed shall be used as the editor.

But other than that, I can't find any reference from POSIX that
mandates that the edit line must be restored after running the `v'
command.

Also, if you run `edit-and-execute-command' when the edit line as a
simple command (say ls), it will run ls, and then clear the edit line.

Reviewing what other shells do:

- ksh93: It won't accept the `v' command while under the secondary prompt
- mksh: Same as ksh93
- dash (compiled with libedit support): If you type  then
return, then ESC-v, it will open the editor on an empty file, and...
well, it nothing of what it does really makes sense.
- zsh's ZLE `edit-command-line': This one works a little different,
since it won't execute the command after the editor exits. Rather,
it'll just put the result in the edit buffer, and then you have to hit
return to execute it.
- posh: doesn't seem to support command line editing.
- NetBSD's /bin/sh: if you run the `v' command while under the
secondary prompt, it will open an editor, but discards what you write
after the editor exits and returns back to the secondary prompt state.

So there doesn't seem to be consensus here.

And I guess that it's more useful if `edit-and-execute-command'
behaves the same way for a single line command or a multiline command.

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 9:44 AM, Eduardo Bustamante  wrote:
[...]
> - dash (compiled with libedit support): If you type  then
> return, then ESC-v, it will open the editor on an empty file, and...
> well, it nothing of what it does really makes sense.
[...]
> - NetBSD's /bin/sh: if you run the `v' command while under the
> secondary prompt, it will open an editor, but discards what you write
> after the editor exits and returns back to the secondary prompt state.

Small correction, these two behave in the same way.

Re: unalias works weirdly inside an if-then block

[Gabor Burjan]

On Fri, May 12, 2017 at 09:10:07AM -0400, Greg Wooledge wrote:
> On Fri, May 12, 2017 at 02:33:06PM +0200, Gabor Burjan wrote:
> > unalias works weirdly inside an if-then block
>
> Because bash has to parse the entire compound command (the entire
> multi-line command up to "fi") before it can begin execution of it.

Greg,

Thanks for your answer.  I'm coping with a legacy "enterprise"
installation framework which opens shell via ssh using expect, and the
target machine was a Red Hat based machine where cp is aliased.  The
part where I could hook the process was after the function definition
which uses cp and therefore blocks the automatic running if cp becomes
interactive.  The original hook was this

if [[ $- =~ i ]]; then
unalias cp
fi

but unfortunately this was later in the script than the function
definition.  It's clear that the interactive mode is for interactive
usage, but I cannot change that part of the script.  Now it's clear that
this will only work if it's on the top of the script, before the
function declaration.

Thanks again both for your help.

Regards,
Gabor

Bash segmentation fault in readline's update_line

[Eduardo Bustamante]

dualbus@debian:~/bash-fuzzing/read-readline$ base64 update_line 秧秧秧
MBs4MOenpzAwMDAwMDAwMBs4OOenpwESGQ==

Core was generated by `/home/dualbus/src/gnu/bash/bash -c read -e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:693
693 ../sysdeps/x86_64/multiarch/memcmp-sse4.S: No such file or directory.
(gdb) bt
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:693
#1  0x00519270 in update_line (
old=0x143c0c7 '秧' , "0", '秧' , ...,
new=0x143b0c7 '秧' , "0", '秧' , ...,
current_line=1, omax=-42, nmax=-42, inv_botlin=5) at display.c:1609
#2  0x00516b5a in rl_redisplay () at display.c:1121
#3  0x00514f04 in rl_display_search (search_string=0x1439808
"0", '秧' , ...,
flags=3, where=-1) at isearch.c:198
#4  0x00514d52 in _rl_isearch_dispatch (cxt=0x1438508, c=25)
at isearch.c:718
#5  0x005138c0 in rl_search_history (direction=-1,
invoking_key=18) at isearch.c:762
#6  0x0051381d in rl_reverse_search_history (sign=1, key=18)
at isearch.c:136
#7  0x004fe8c7 in _rl_dispatch_subseq (key=18, map=0x772d90
, got_subseq=0) at readline.c:851
#8  0x004fe269 in _rl_dispatch (key=18, map=0x772d90
) at readline.c:797
#9  0x004fe1d9 in readline_internal_char () at readline.c:629
#10 0x004ff7c2 in readline_internal_charloop () at readline.c:656
#11 0x004fdb32 in readline_internal () at readline.c:670
#12 0x004fd9f0 in readline (prompt=0x5513f9 "") at readline.c:374
#13 0x004cd106 in edit_line (p=0x5513f9 "", itext=0x0) at
./read.def:1090
#14 0x004cbc33 in read_builtin (list=0x0) at ./read.def:554
#15 0x0044efcf in execute_builtin (builtin=0x4cada0
, words=0x13dc688, flags=64, subshell=0)
at execute_cmd.c:4605
#16 0x0044e400 in execute_builtin_or_function
(words=0x13dc688, builtin=0x4cada0 , var=0x0,
redirects=0x0,
fds_to_close=0x13dbe08, flags=64) at execute_cmd.c:5103
#17 0x004470b5 in execute_simple_command
(simple_command=0x13dbd88, pipe_in=-1, pipe_out=-1, async=0,
fds_to_close=0x13dbe08)
at execute_cmd.c:4391
#18 0x00444b91 in execute_command_internal (command=0x13dbd48,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x13dbe08) at execute_cmd.c:812
#19 0x004c1ff7 in parse_and_execute (string=0x13c4268 "read
-e", from_file=0x535c9f "-c", flags=4) at evalstring.c:430
#20 0x004271af in run_one_command (command=0x7ffc7981a719
"read -e") at shell.c:1405
#21 0x004251fd in main (argc=3, argv=0x7ffc79818ea8,
env=0x7ffc79818ec8) at shell.c:718


(gdb) p old
$1 = 0x8880c7 '秧' , "0", '秧' , ...
(gdb) p new
$2 = 0x8870c7 '秧' , "0", '秧' , ...
(gdb) call strlen(old)
$3 = 859
(gdb) call strlen(new)
$4 = 859
(gdb) p temp
$5 = -42

Re: Bash doesn't handle C with acute accent properly during readline's rl_change_case

[Chet Ramey]

On 5/11/17 8:56 AM, Eduardo Bustamante wrote:
> The C with acute accent character: https://en.wikipedia.org/wiki/%C4%86
> 
> - Upper case
> dualbus@debian:~$ printf '\U0106\n'
> Ć
> 
> - Lower case
> dualbus@debian:~$ printf '\U0107\n'
> ć
> 
> Now, in bash, if you type in ć, then run readline `upcase-word' on it,
> instead of ending up with the UTF-8 multibyte string for U+0106 (0xC4
> 0x86), you end up with 0x07 0x87.
> 
> The parameter expansion doesn't seem to have that problem so I think
> it's a bug in readline:

Thanks for the report. This is a bug in readline.

> For some reason, rl_change_case thinks `c` is ASCII:
> 
> (gdb) call isascii((unsigned char)c)
> $8 = 1

Because when you cast it to unsigned char, it masks all but the least
significant 8 bits, which results in a valid ascii character.


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

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Chet Ramey]

On 5/12/17 10:44 AM, Eduardo Bustamante wrote:

> But other than that, I can't find any reference from POSIX that
> mandates that the edit line must be restored after running the `v'
> command.

Because it doesn't say the equivalent of "execute the current command
line" (as newline does), it's a standard editing command that continues
with the current line buffer. The only thing that gets executed are the
contents of the temp file.

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

Re: Compiling bash statically in 4.2/4.3/4.4 with GCC 6.1.0

[Chet Ramey]

On 5/12/17 9:55 AM, Eduardo Bustamante wrote:
> FWIW, I'm able to compile bash statically with:
> 
> dualbus@debian:~/src/gnu/bash$ ./configure --enable-static-link
> --without-bash-malloc
> [...]
> dualbus@debian:~/src/gnu/bash$ make
> [...]

During which you get a million warnings about using any of the username/
group/service/hostname lookup functions in a static executable without
the dynamic libraries available.


> It fails if I try to use clang though:
[...]
> It seems to be caused by the combination of `-static' and `rdynamic'
> (from LOCAL_LDFLAGS). This "works" though:

The -rdynamic is in there to support `enable -f', though I don't know
whether it's reasonable to expect that to work when you link with the
static libraries.

Chet

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