Re: TIMEFORMAT in time ( )

[Eduardo A . Bustamante López]

The attached patch "fixes" this:

hp% ./bash -c 'time (TIMEFORMAT=y)'

real0m0.001s
user0m0.000s
sys 0m0.000s
hp% bash -c 'time (TIMEFORMAT=y)' 
y

Disclaimer: I don't know if it's a good patch. It may break stuff.

This problem is caused due to bash passing `time ( ... )' as a COMMAND with
type = cm_subshell and flags = CMD_TIME_PIPELINE to execute_command_internal,
but since the case to handle type = cm_subshell is before the case to handle
flags = CMD_TIME_PIPELINE, the program forks, the time_command is executed
inside the new process and we all know what happens next.

My patch just adds a special case for this situation, and passes the command
directly to time_command.

I guess it might be better to just move the block of code handling the general
case when flags = CMD_TIME_PIPELINE, but I don't know if this will have any
undesired consequences.
diff --git a/execute_cmd.c b/execute_cmd.c
index def409f..9e17386 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -588,6 +588,13 @@ execute_command_internal (command, asynchronous, pipe_in, 
pipe_out,
   if (command->type == cm_subshell && (command->flags & CMD_NO_FORK))
 return (execute_in_subshell (command, asynchronous, pipe_in, pipe_out, 
fds_to_close));
 
+#if defined (COMMAND_TIMING)
+  if (command->type == cm_subshell && command->flags & CMD_TIME_PIPELINE)
+{
+ return time_command (command, asynchronous, pipe_in, pipe_out, 
fds_to_close);
+   }
+#endif /* COMMAND_TIMING */
+
 #if defined (COPROCESS_SUPPORT)
   if (command->type == cm_coproc)
 return (execute_coproc (command, pipe_in, pipe_out, fds_to_close));

Re: forked before bash subshell

[L. A. Walsh]

Ya know, if you are looking for optimization opportunities, using
a temporary file to communicate between processes rather than
using an actual pipe, is definitely a performance hit --
ESPECIALLY on Cygwin, where you can't even do a "stat" call on
a file without actually opening the file.

I seem to remember a few months back mentioning this inefficiency and
how in some environments, using a tmp file (say booting from a read-only
media, and having no writable, temporary, storage) might not just be
slow, but fail to work.  Some were sure a startup script I was working
on at the time, was running into problems with TMP not being writable
on linux.

So in addition to fixing a performance issue on Cygwin, using pipes
for communication could actually make bash work in more places where it
might not otherwise.

I didn't get the impression that you were willing to look for issues
to improve bash's performance or improve bash's robustness at that time.

Just thought I'd refresh your memory, if you were open to looking at
areas where algorithmic improvement would be likely to result in
increased performance and robustness...

:-)
Linda


Chet Ramey wrote:

It's not a bug; it's an opportunity for optimization. It's like this
because it hasn't come up as a performance problem.  I'll take a look
at it.  There are probably several opportunities like this.

Chet

  

Assigning to BASHPID fails silently

[Martijn Dekker]

bash 4.4.0 (I did not investigate other versions) does not produce an
error message if you try to assign something to the BASHPID readonly
using either arithmetic or normal assignment. Other readonlies produce a
message on an assignment attempt. BASHPID seems to be an exception.


Particularly annoying is that a non-interactive shell will exit silently
on a mistaken attempt to assign to BASHPID. I was making a bash function
to determine if we're in a subshell. Because of the lack of error
message, it took some doing to find my typo in
return "$((BASHPID = $$))"
(of course, comparison is '==' and not '='). Not even 'set -x' will give
a clue; it exits before producing relevant tracing output.


Proof below. (The exit status of the previous command is included in the
prompt in the output below.)

[0]$ UID=0
bash: UID: readonly variable
[1]$ BASHPID=0
[1]$ ((UID=0))
bash: UID: readonly variable
[1]$ ((BASHPID=0))
[1]$

Thanks,

- Martijn