Aw: Re: Completion of ENV variables seems to be broken - leading slash (or even more) is added

[pjodrr]

Hello,

Am Dienstag, 15. März 2011 21:44:37 UTC+1 schrieb Chet Ramey:
> 
> The bash-4.1 solution, though it modified what the user typed, did not
> result in any ambiguity.  A filename was a filename, and if it contained
> characters that needed to be quoted, readline did so.
> 
> I might be able to finesse this issue and retain the bash-4.2 behavior
> by changing state when rewriting the directory name for opendir(2), but
> I have to think about it some more.

you elsewhere suggested to write a completion function for cd
that does the expansion.  May I point out that the expansion
of variables is not only a matter with the cd command but
for any other command that expects directory or file names?
I understand the dilemma, nobody prevents me from creating
a directory named '$HOME' but what do I expect when typing
cd $HOME/...?
Anyways I just installed Bash 4.2 and many people here would like
the old behaviour back.  It is quite common to do
`ls $VAR/' and then expecting that $VAR is expanded,
I don't think that anybody here has a file name containing
a dollar, and if that would be the case, then I doubt that
what follows the dollar sign is a name of a variable.

Thanks,

  Peter

Aw: Re: Completion of ENV variables seems to be broken - leading slash (or even more) is added

[pjodrr]

Hello,

Am Montag, 11. Juli 2011 04:08:13 UTC+2 schrieb Chet Ramey:
> This will be optional behavior in the next release of bash.  Users will
> be able to choose whether or not they want word completion to perform
> variable expansion and update the command line with the results.

that's good news, we are looking forward to that!

Thanks,

  Peter

Aw: Re: Inline `ifdef style` debugging

[pjodrr]

Hello,

Am Montag, 8. August 2011 19:20:25 UTC+2 schrieb Steven W. Orr:
> 
> if (( debug ))
> then
>  _debug()
>  {
>  "$@"
>  # I do question whether this is a viable construct, versus
>  # eval "$@"
>  }
> else
>  _debug()
>  {
>  :
>  }
> fi
> 

on bash-hackers.org I found this, which I think is the ultimate
method to write a debug-function:

_debug() {
if $whatever_test_you_prefer; then
_debug() {
"$@"
}
else
_debug() {
:
}
fi
_debug "$@"
}

they call it "collapsing functions":
http://wiki.bash-hackers.org/howto/collapsing_functions

have fun,

  Peter

Aw: Re: Re: Inline `ifdef style` debugging

[pjodrr]

Am Donnerstag, 11. August 2011 14:13:27 UTC+2 schrieb Greg Wooledge:
> The problem with this is that you can't switch to the other function
> later.

this is intended.  The idea is to call a script with a debug
or no-debug option.  So for the runtime of the script the
debug() function does not change.

> Here, the first call to chatter blows away the test of $verbose, so
> the next time we call it, the fact that we've set verbose=1 is ignored.
> We're stuck in non-verbose mode forever.

if you want a different behaviour you have to test for $verbose
everytime the chatter() is called which was to be avoided.

cheers

Aw: Re: Re: Inline `ifdef style` debugging

[pjodrr]

Am Donnerstag, 11. August 2011 12:40:24 UTC+2 schrieb Roger:
> Just a quick response here, "ifdef style" is C code not compiled into the
> compiled program if it is not defined or chosen to be enabled.  This in turn,
> prevents the CPU from wasting cycles testing if/then statements, etc...

yes, I understood that, you want some kind of preprocessing.  With the
given examples the test for $DEBUG is done only once in the runtime of
the script.  If you want to avoid that as well, you need two different
scripts, one with debugging enabled and one without.  These scripts
can be the result of a preprocessing of course.

regards

output redirection with process substitution asynchronous?

[pjodrr]

Hello,

how can I prefix every line of output of some command with a
timestamp?  I thought like this:

$ exec 3> >(while read line; do echo "$(date): $line"; done)
$ seq 4 >&3
Friday, December  4, 2009  4:20:29 PM MET: 1
$ Friday, December  4, 2009  4:20:29 PM MET: 2
Friday, December  4, 2009  4:20:29 PM MET: 3
Friday, December  4, 2009  4:20:29 PM MET: 4

please note that the prompt ($) returns before the command completes.
Why is the
process substitution asynchronous?
Does anybody know of a better way to accomplish this?

Thanks,

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

On Dec 4, 7:46 pm, DennisW  wrote:
>
> This should be in gnu.bash rather than gnu.bash.bug

oh, you are right, it's not a bug yet

> Would this work for you?
>
> while read line; do echo "$(date): $line $((num++))"; done

ah sorry, I used the command "seq" just as an example, it could
be any other command that produces output, should have probably
written like:

$ exec 3> >(while read line; do echo "$(date): $line"; done)
$  >&3
Friday, December  4, 2009  4:20:29 PM MET: 1
$ Friday, December  4, 2009  4:20:29 PM MET: 2
Friday, December  4, 2009  4:20:29 PM MET: 3
Friday, December  4, 2009  4:20:29 PM MET: 4

thanks,

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

Hi

On Dec 4, 7:58 pm, pk  wrote:
> What's wrong with
>
> seq 4 | while read line; do echo "$(date): $line"; done

it creates a subshell, "seq" was just an example, sorry for
the confusion, it could be any other command, and it
should run in the current shell.

thanks,

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

Hello,

On Dec 4, 8:18 pm, DennisW  wrote:
> It works for me. Does it not for you? If you're asking why not do it,
> then the answer is "why call an external program unnecessarily?".
>
> Sorry, by the way, I missed what you were doing with the file
> descriptor on my first read. What is it that you're trying to
> accomplish? Are you doing this only to number the lines or is either
> seq or the while loop a stand-in for something else?

the seq was only an example for demonstration.
here is another example that shows what I mean:

$ exec 3> >(while read line; do echo "tag: $line"; done)
$ seq 4 >&3
tag: 1
tag: 2
tag: 3
tag: 4

$ exec 3> >(while read line; do echo "$(date): $line"; done)
$ seq 4 >&3
$ Sat Dec  5 10:11:25 CET 2009: 1
Sat Dec  5 10:11:25 CET 2009: 2
Sat Dec  5 10:11:25 CET 2009: 3
Sat Dec  5 10:11:25 CET 2009: 4

while in the first example the prompt returns after the
command completes, the prompt returns immediately
in the second example.

thanks for your attention,

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

On Dec 5, 4:45 pm, pk  wrote:
> pjodrr wrote:
> > Hi
>
> > On Dec 4, 7:58 pm, pk  wrote:
> >> What's wrong with
>
> >> seq 4 | while read line; do echo "$(date): $line"; done
>
> > it creates a subshell
>
> uh...where do you think your original
>
> >(while read line; do echo "$(date): $line"; done)
>
> runs?

in my original example the "seq 4" runs in the current shell
while here the command runs in a subshell.

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

On Dec 5, 3:51 pm, DennisW  wrote:
> On Dec 5, 3:14 am, pjodrr  wrote:
>
>
>
> > Hello,
>
> > On Dec 4, 8:18 pm, DennisW  wrote:
>
> > > It works for me. Does it not for you? If you're asking why not do it,
> > > then the answer is "why call an external program unnecessarily?".
>
> > > Sorry, by the way, I missed what you were doing with the file
> > > descriptor on my first read. What is it that you're trying to
> > > accomplish? Are you doing this only to number the lines or is either
> > > seq or the while loop a stand-in for something else?
>
> > the seq was only an example for demonstration.
> > here is another example that shows what I mean:
>
> > $ exec 3> >(while read line; do echo "tag: $line"; done)
> > $ seq 4 >&3
> > tag: 1
> > tag: 2
> > tag: 3
> > tag: 4
>
> > $ exec 3> >(while read line; do echo "$(date): $line"; done)
> > $ seq 4 >&3
> > $ Sat Dec  5 10:11:25 CET 2009: 1
> > Sat Dec  5 10:11:25 CET 2009: 2
> > Sat Dec  5 10:11:25 CET 2009: 3
> > Sat Dec  5 10:11:25 CET 2009: 4
>
> > while in the first example the prompt returns after the
> > command completes, the prompt returns immediately
> > in the second example.
>
> > thanks for your attention,
>
> >   Peter
>
> Your example here:
>
> $ exec 3> >(while read line; do echo "tag: $line"; done)
> $ seq 4 >&3
>
> just executes too quickly to exhibit this behavior. Try this and it
> will do it, too:
>
> $ exec 3> >(while read line; do for i in {1..1}; do :; done; echo
> '.'; done)

this results in:

malloc: ../bash/subst.c:4198: assertion botched
realloc: start and end chunk sizes differ
last command: exec 3> >(while read line; do for i in {1..1}; do :;
done; echo '.'; done)
Aborting...Aborted

but I see your point of course.

> $ seq 4 >&3
>
> I think the thing to remember is that doing this is like running
> something in the background with "&". So, yes, it's going to be
> asynchronous.

thanks for your explanation.  Is there any way to avoid this
behaviour?
There is probably no way to wait for the completion, is there?
Other than like this:

fifo=$(mktemp -u) || exit
mkfifo $fifo || exit
trap "rm -f $fifo" 0
trap exit 1 2 15
while read line; do echo "$(date): $line"; done < $fifo &
prefix_pid=$!
seq 4 > $fifo
wait $prefix_pid

Or how would you accomplish this?

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

Hi Marc,

On Dec 7, 5:25 pm, Marc Herbert  wrote:
> Marc Herbert wrote:
> > What is wrong with the following:
>
> > prefix_with_date ()
> > {
> >     while read; do
> >         printf '%s: %s\n' "$(date)" "$REPLY";
> >     done
> > }
>
> > seq 4 | prefix_with_date
> > ls | prefix_with_date
>
> Sorry I missed the fact that you want to run your commands in the current 
> shell.
>
> There are no real coroutines in shell. The current shell process does
> not know how to schedule two pieces of code. So each time two
> pieces of code communicate through a pipe they have to be run in two
> *concurrent* processes (typically: subshells).  The producer and
> consumer of a pipe must run independently of each other. Whether you
> are using process substitution or the more usual and portable pipe "|"
> does not matter here: you need concurrency.
>
> So at least one of: 1. your prefixer code, 2. your unknown command
> has to run in a independent process, "asynchronous" with the current
> shell.
>
> Since you absolutely want your unknown commands to run in the current
> shell, then it is your "prefixing" code that has to run in a
> concurrent process.
>
> Now I do not really see any other way to avoid the ugliness of
> concurrently printing on stdout than to "wait" for your concurrent
> prefixer to complete, more or less like you did.
>
> A variant is to ask socat to handle the cleanup actions for you like
> this:
>
> prefix_with_date()
> {
>     local P=/tmp/dataorig.$$
>     socat -u  PIPE:${P}  SYSTEM:'while read; do echo "$(date):\\ $REPLY"; 
> done'   &
>     socatPID=$!
>     until [ -e ${P} ]; do sleep 1; done
>     $@ > ${P}
>     wait $socatPID
>
> }
>
> prefix_with_date  seq 5

thank you very much for your explanation!  I feel understood  and will
think about
using socat and if I want my script to depend on another program.  But
at least
it became clear that the builtin process substitution is not the
solution for me.

Regards,

  Peter

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

On Dec 8, 11:05 am, Marc Herbert  wrote:
> pk a écrit :
>
>
>
> > I disagree. All the further changes in the requirements because creating a
> > subshell or being asynchronous is not acceptable etc. are not a goal in
> > themselves, but rather the indicators that he's trying to accomplish
> > something else.
>
> I think he just want side-effects like in this recent example from Chris:
>
> 
>
> Granted: if he was explaining in greater detail which side-effects he wants,
> people might be able to suggest better alternatives.

I promise I'll do better the next time.

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

On Dec 8, 10:55 am, Marc Herbert  wrote:
> DennisW wrote :
>
> > Would you care to comment on the coproc command in Bash 4?
>
> I wish I could, but I know nothing about it. Anyone else?

yeah, I tried that:

prefix_timestamp() {
while read line; do
echo "$(date): $line"
done
}

coproc prefix_timestamp
seq 10>&${COPROC[1]}
eval "exec ${COPROC[1]}>&-"
cat <&${COPROC[0]}
wait $COPROC_PID

but am not sure if I like that construct better.

  Peter

Re: output redirection with process substitution asynchronous?

[pjodrr]

Hello again,

I have to reply to my own post to correct it:

On Dec 8, 2:00 pm, pjodrr  wrote:
> coproc prefix_timestamp
> seq 10>&${COPROC[1]}
> eval "exec ${COPROC[1]}>&-"
> cat <&${COPROC[0]}
> wait $COPROC_PID

replace this with:

{ coproc prefix_timestamp >&3 ; } 3>&1
seq 10>&${COPROC[1]}
eval "exec ${COPROC[1]}>&-"
wait $COPROC_PID

this is how i do it now, thanks for the discussion.

  Peter

Re: Bash-4.1 available for FTP

[pjodrr]

Hello,

On Jan 2, 6:41 pm, Chet Ramey  wrote:
> Unlike previous bash distributions, this tar file includes the formatted
> documentation (postscript, dvi, html, and nroffed versions of the manual
> pages).

which makes the proxy/firewall of the company i'm working for atm
block the download because it suspects a "textual file with binary
content."
I'll probably find a way to get the code, it only shows that every
change can
have unforseen consequences.

Happy new year!

  Peter