Re: trap DEBUG and $_

[Geir Hauge]

On Mon, Oct 12, 2015 at 07:24:00AM +0200, isabella parakiss wrote:
> On 10/11/15, Dan Stromberg  wrote:
> > Is there a way of outputting a datestamp to shell stderr at the _beginning_
> > of the execution of a command, that won't wipe out $_?
> >
> > I use $_ quite a bit for the last argument to the previous command,
> > interactively.  And I'd like to datestamp all my commands. Datestamping
> > after with $PS1 is easy, but datestamping before is a little harder.
> >
> > I've tried using:
> >
> >function preexec { if tty -s; then echo "$(tput smso)cmd started $(date
> > +%Y\ %a\ %b\ %d\ %r)$(tput rmso)"; fi; }
> >trap preexec DEBUG
> >
> > ...but as you might suspect, I'm finding that $_ is always "preexec" with
> > this enabled.
> >
> > Any suggestions?
> >
> > Thanks!
> >
> trap '__=$_; preexec; : "$__"' DEBUG

And since the preexec function ignores its arguments, it can be
shortened to:

trap 'preexec "$_"' DEBUG

-- 
Geir Hauge

Re: ! in PS1 in posix mode

[Greg Wooledge]

On Mon, Oct 12, 2015 at 09:28:42AM -0700, Linda Walsh wrote:
> Chet Ramey wrote:
> >http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
> >
> >"The shell shall replace each instance of the character '!' in PS1 with
> >the history file number of the next command to be typed."
> 
> I've never seen that -- even when my prompt has
> ! in it...maybe it's cause I have histexpand 'off'?

Same here.

imadev:~$ PS1=' ! > '
 ! > 

If that's a bug, please don't "fix" it.

Re: ! in PS1 in posix mode

[Linda Walsh]

Chet Ramey wrote:

On 10/11/15 1:37 AM, isabella parakiss wrote:

In posix mode, bash replaces ! in my PS1 with the history number.


http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03

"The shell shall replace each instance of the character '!' in PS1 with
the history file number of the next command to be typed."


I've never seen that -- even when my prompt has
! in it...maybe it's cause I have histexpand 'off'?

Re: Something strange with string replacements

[Greg Wooledge]

On Sun, Oct 11, 2015 at 04:33:11PM -0700, gaspar@gmail.com wrote:
> I was just testing if I could do some things with bash and the I came across 
> this:
> $ tigres="Un tigre, dos tigres, tres tigres"
> $ echo ${tigres//[A-Z]/[a-z]}
> 
> tt [a-z][a-z][a-z][a-z][a-z], Ale cto kkk log nfs tes tmp tst www 
> [a-z][a-z][a-z][a-z][a-z][a-z], aeat home kaka lmms Mail prog temp test 
> Clases kernel kfreir Mariah Música system unbind Vídeos webdav
> 
> The reply was strange, Ale, cto, kkk, log, nfs, tes... are files in the 
> current directory where I'm running this.

The [a-z] on the right hand side is a literal string that your letters
are replaced by.  So in the first pass, depending on how your current
locale is defined by your operating system, your input string is replaced
by something like:

[a-z][a-z] [a-z][a-z][a-z][a-z][a-z], [a-z][a-z][a-z] 
[a-z][a-z][a-z][a-z][a-z][a-z], [a-z][a-z][a-z][a-z] 
[a-z][a-z][a-z][a-z][a-z][a-z]

(You can see that by quoting your parameter expansion properly!)

In the second pass, which occurs since you DIDN'T quote the parameter
expansion, each of these glob-style patterns is replaced by all matching
file names.  In your example, [a-z][a-z] is obviously replaced by tt.
And then [a-z][a-z][a-z] is replaced by Ale cto kkk log nfs tes tmp tst www.
And so on.

So, you have several complex things going on here:

1) In your locale, [A-Z] matches more than just uppercase letters.
2) [a-z] is a literal string, not a tr(1)-style replacement group.
3) You didn't quote the parameter expansion, so sequences of [a-z]...
   are replaced by filenames in $PWD.

imadev:~/tmp$ touch Ale cto kkk log nfs tes
imadev:~/tmp$ tigres="Un tigre, dos tigres, tres tigres"
imadev:~/tmp$ echo "${tigres//[A-Z]/[a-z]}"
[a-z][a-z] [a-z][a-z][a-z][a-z][a-z], [a-z][a-z][a-z] 
[a-z][a-z][a-z][a-z][a-z][a-z], [a-z][a-z][a-z][a-z] 
[a-z][a-z][a-z][a-z][a-z][a-z]
imadev:~/tmp$ echo ${tigres//[A-Z]/[a-z]}
[a-z][a-z] [a-z][a-z][a-z][a-z][a-z], cto kkk log nfs tes 
[a-z][a-z][a-z][a-z][a-z][a-z], [a-z][a-z][a-z][a-z] 
[a-z][a-z][a-z][a-z][a-z][a-z]
imadev:~/tmp$ locale
LANG=en_US.iso88591
LC_CTYPE="en_US.iso88591"
LC_COLLATE="en_US.iso88591"
LC_MONETARY="en_US.iso88591"
LC_NUMERIC="en_US.iso88591"
LC_TIME=POSIX
LC_MESSAGES="en_US.iso88591"
LC_ALL=

In the C locale, you would very likely get different results:

imadev:~/tmp$ (LC_ALL=C; echo "${tigres//[A-Z]/[a-z]}")
[a-z]n tigre, dos tigres, tres tigres

On my system, as you can see, [A-Z] in the en_US.iso88591 locale matches
both upper- and lowercase letters (but possibly not all of them).  In
the C locale, [A-Z] matches only A, B, C, D, ..., Z.  Your system may
have a different locale definition.

Also note that recent versions of bash has a globasciiranges shopt,
which changes the meaning of [A-Z] and [a-z].  Clearly you did not
have this option enabled, but you may want to play around with it to
see how it changes your code.

Re: ! in PS1 in posix mode

[isabella parakiss]

On 10/12/15, Greg Wooledge  wrote:
> On Mon, Oct 12, 2015 at 09:28:42AM -0700, Linda Walsh wrote:
>> Chet Ramey wrote:
>> >http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
>> >
>> >"The shell shall replace each instance of the character '!' in PS1 with
>> >the history file number of the next command to be typed."
>>
>> I've never seen that -- even when my prompt has
>> ! in it...maybe it's cause I have histexpand 'off'?
>
> Same here.
>
> imadev:~$ PS1=' ! > '
>  ! >
>
> If that's a bug, please don't "fix" it.
>
Out of posix mode, the history number is \!

---
xoxo iza

404 error when accessing "6.9 Controlling the Prompt" in the manual

[Adrian Fita]

I get 404 when I try to access "6.9 Controlling the Prompt" from the
manual, "HTML - with one web page per node" version.

I get the page not found error from the following pages:
- https://www.gnu.org/software/bash/manual/html_node/index.html#SEC_Contents
- 
https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Variables.html#index-PS1
- 
https://www.gnu.org/software/bash/manual/html_node/Concept-Index.html#Concept-Index

May be more.

Thanks,
--
Fita Adrian

Re: ! in PS1 in posix mode

[Chet Ramey]

On 10/12/15 12:28 PM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
>> On 10/11/15 1:37 AM, isabella parakiss wrote:
>>> In posix mode, bash replaces ! in my PS1 with the history number.
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
>>
>>
>> "The shell shall replace each instance of the character '!' in PS1 with
>> the history file number of the next command to be typed."
> 
> I've never seen that -- even when my prompt has
> ! in it...maybe it's cause I have histexpand 'off'?

It happens in posix mode.

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

Re: Continue behavior in devel branch

[Carlos Pita]

Ok, I see. Thank you for the answer.

I've already found a program (yaourt) that wreaks havoc because of
this, I gave its developers a heads up.

The cause of my question is that I want to use your readline devel
branch. First, I thought I would need to use the bash devel branch
too, but then I realized that just recompiling the stable branch
against readline devel would be enough. So the disruptive continue
behaviour is not really an issue for me, as I've thought at first.
Nevertheless, there is still the problem of recompiling and replacing
the system-wide /bin/bash because most of the bash scripts will use
it. This is easy in my arch linux but not so easy in production
servers where I use readline a lot.

Do you have plans to backport the improvements in readline that
doesn't require a change in the binary interface? If not, would it be
too difficult to do it myself?

Cheers
--
Carlos

On Sat, Oct 10, 2015 at 1:51 PM, Chet Ramey  wrote:
> On 10/10/15 9:36 AM, Carlos Pita wrote:
>> Hi Chet,
>>
>> consider the following program:
>>
>> yyy() {
>>   continue
>> }
>>
>> xxx() {
>>   while true; do
>> echo x
>> yyy
>> echo y
>> break
>>   done
>> }
>>
>> xxx
>>
>> In the bash devel branch it will ignore the continue and echo
>>
>> x
>> y
>
> The change was made intentionally.  Historical versions of sh ignore (or
> more precisely reset) the loop state when entering a shell function, so
> the continue doesn't have any effect.  Posix doesn't say anything specific
> about it, but it doesn't call out a change from the historical behavior,
> so it came up reported as a bug.
>
> The discussion about the change took place on the dash mailing list,
> but the gmane.org archives are down right now so I can't give you a URL.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: 404 error when accessing "6.9 Controlling the Prompt" in the manual

[Chet Ramey]

On 10/12/15 9:14 AM, Adrian Fita wrote:
> I get 404 when I try to access "6.9 Controlling the Prompt" from the
> manual, "HTML - with one web page per node" version.
> 
> I get the page not found error from the following pages:
> - https://www.gnu.org/software/bash/manual/html_node/index.html#SEC_Contents
> - 
> https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Variables.html#index-PS1
> - 
> https://www.gnu.org/software/bash/manual/html_node/Concept-Index.html#Concept-Index

http://lists.gnu.org/archive/html/bug-bash/2015-03/msg00039.html


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

Re: Continue behavior in devel branch

[Carlos Pita]

> If not, would it be too difficult to do it myself?

On a second thought, it would be easier for me to just revert the
binary incompatible changes, assuming they're not too entangled with
the rest. Could you give me some hints? Thank you very much.

Re: read and env variables + POSIX => SEGFAULT

[Chet Ramey]

On 10/10/15 11:01 PM, Linda Walsh wrote:

>> a= read a <<< x;echo $?
> 0
>> declare -p a
> declare -- a="x"
> #  the manpage claims "one line is read from [the input], and the result
> #  is split by words and assigns 1st word to 1st var and so forth, but
> #  apparently the reading of 1 line is optional -- though this is consistent
> #  with the fact that read can be told to read some number of characters
> and #  return when the limit is reached.  So technically, read doesn't
> "read one line",
> #  but read whatever is on 'input' up to 1 line.  (DOC clarification?)

This is terribly wrong.

The command in question is `a= read a <<< x'.

The here-string construct takes the following word and, like a here
document, makes it the standard input to the command.  The standard
input is then a file consisting of a single line: x\n.

It's basically shorthand for

read a 

Re: read and env variables + POSIX => SEGFAULT

[Linda Walsh]

(Cc: Chet Ramey... forgot to send it to list...oop)


Chet Ramey wrote:

On 10/10/15 11:01 PM, Linda Walsh wrote:


a= read a <<< x;echo $?

0

declare -p a

declare -- a="x"
#  the manpage claims "one line is read from [the input], and the result
#  is split by words and assigns 1st word to 1st var and so forth, but
#  apparently the reading of 1 line is optional -- though this is 
consistent

#  with the fact that read can be told to read some number of characters
and #  return when the limit is reached.  So technically, read doesn't
"read one line",
#  but read whatever is on 'input' up to 1 line.  (DOC clarification?)


This is terribly wrong.

The command in question is `a= read a <<< x'.

The here-string construct takes the following word and, like a here
document, makes it the standard input to the command.  The standard
input is then a file consisting of a single line: x\n.

It's basically shorthand for

read a <

I wasn't sure if it put the "\n" at the end in a 1-line example.

Does it also use a tmp file and use process-substitution, or is
that only when parens are present?  I.e.

read a < <( echo x)

I'm under the impression, uses a tmp file.

does the read a <<< x
also use a tmp file?

I.e. is

readarray -t a < <( echo -e 'x\ny\n')
declare -p a

declare -a a='([0]="x" [1]="y")'

implemented the same way as

a=(x y)
b=$(printf "%s\n" ${a[@]})
readarray -t ar <<< "${b[@]}"
declare -p a

declare -a a='([0]="x" [1]="y")'

Re: ! in PS1 in posix mode

[Linda Walsh]

Chet Ramey wrote:

On 10/12/15 12:28 PM, Linda Walsh wrote:


Chet Ramey wrote:

On 10/11/15 1:37 AM, isabella parakiss wrote:

In posix mode, bash replaces ! in my PS1 with the history number.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03


"The shell shall replace each instance of the character '!' in PS1 with
the history file number of the next command to be typed."

I've never seen that -- even when my prompt has
! in it...maybe it's cause I have histexpand 'off'?


It happens in posix mode.

---
How lame!  It's a '!' in a quoted string.  Another example
of posix braindeath -- how long before people realize that the
thing branded 'posix' now isn't the real posix that was started
to *describe* behaviors, not prescribe or proscribe behaviors.
They just bought the name -- like PacBell swallowed SW Bell and
then bought the AT name (not the labs... just the name).  So that
AT today is really the old PacBell in new shoes...

It's like its really tweaky watching a first run anime from
Japan (in japanese) with a Universal logo on it... and words that it is
an NBC company.  (Who is now owned by Comcast).

Oh well when I role my own, I think I usually leave
histexpand out of it.  Having to remember line numbers seems
ridiculous... and I can search by hitting ESC /string (in vi
mode anyway).

-l

Re: read and env variables + POSIX => SEGFAULT

[Chet Ramey]

On 10/12/15 7:39 PM, Linda Walsh wrote:

 a= read a <<< x;echo $?
>>> 0
 declare -p a
>>> declare -- a="x"
>>> #  the manpage claims "one line is read from [the input], and the result
>>> #  is split by words and assigns 1st word to 1st var and so forth, but
>>> #  apparently the reading of 1 line is optional -- though this is
>>> consistent
>>> #  with the fact that read can be told to read some number of characters
>>> and #  return when the limit is reached.  So technically, read doesn't
>>> "read one line",
>>> #  but read whatever is on 'input' up to 1 line.  (DOC clarification?)
>>
>> This is terribly wrong.
>>
>> The command in question is `a= read a <<< x'.
>>
>> The here-string construct takes the following word and, like a here
>> document, makes it the standard input to the command.  The standard
>> input is then a file consisting of a single line: x\n.
>>
>> It's basically shorthand for
>>
>> read a <> x
>> EOF
>>
>> So, `read' reads the single line from its standard input and assigns it
>> to the variable `a'.
> 
> I wasn't sure if it put the "\n" at the end in a 1-line example.

Yes.  All the lines in a here-document or here-string are newline-
terminated.

> Does it also use a tmp file and use process-substitution, or is
> that only when parens are present?

Here-documents and here-strings use temporary files and open them as
the standard input (or specified file descriptor) for the command.

> 
> read a < <( echo x)
> 
> I'm under the impression, uses a tmp file.

Why would you think that?  The documentation clearly says it uses a named
pipe or a file descriptor associated with a /dev/fd filename (which happens
to be a pipe in this case).

> 
> does the read a <<< x
> also use a tmp file?

Yes.

> 
> I.e. is
>> readarray -t a < <( echo -e 'x\ny\n')
>> declare -p a
> declare -a a='([0]="x" [1]="y")'
> 
> implemented the same way as
>> a=(x y)
>> b=$(printf "%s\n" ${a[@]})
>> readarray -t ar <<< "${b[@]}"
>> declare -p a
> declare -a a='([0]="x" [1]="y")'

No, if you mean the type of object the `readarray' command has associated
with its standard input.  The first case is a pipe or FIFO; the second is
a regular file.

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

Re: posix handling of mapfile: SEGFAULT

[Linda Walsh]

Chet Ramey wrote:

Thanks for the report.  I fixed this, and the fix is in the devel branch.



`mapfile' only takes a single variable name argument, and ignores others.
This is identical to the first example.

---
I see... but it pointed out that declare doesn't
actually die until it touch's b, otherwise we wouldn't
have seen the "a: not found"...  not that you needed
that info to isolate the problem.

Re: ! in PS1 in posix mode

[Linda Walsh]

Chet Ramey wrote:

On 10/12/15 7:02 PM, Linda Walsh wrote:


It happens in posix mode.

---
How lame!  It's a '!' in a quoted string.  Another example
of posix braindeath -- how long before people realize that the
thing branded 'posix' now isn't the real posix that was started
to *describe* behaviors, not prescribe or proscribe behaviors.


Do you realize that this prompt expansion was in ksh since at least
ksh-86?  ksh-88 was one of the Posix base documents, and that
expansion was estabished behavior by the time Posix started its work.

---
Haven't used ksh for some timeI thought the '!' stuff came
from csh?  It seemed so pointless, since having to look up
things by command number I thought, was way too much work... searching
via a string in the line seemed so much faster...

For stuff I typed last week or earlier, I'd use grep on the hist files.

I thought to have all my hist files merged and deduped... but the resulting
master hist file -- .. I used it for a while (somewhat accidently  as it was
renamed to a normal hist file @ around 2-3M in length).

command response was quite slow (took a while to figure out it was
the history updating every command that caused a delay of about
2-3 seconds/command).  
I don't think I have all the kinks in the combining routines worked

out yet either... but certainly wouldn't want to switch to the newest
master @ 6.4M until history updating is sped up a bit... (I'm not
holding my break... at least I can still browse/grep it by tty#)...

Re: ! in PS1 in posix mode

[Chet Ramey]

On 10/12/15 7:02 PM, Linda Walsh wrote:

>> It happens in posix mode.
> ---
> How lame!  It's a '!' in a quoted string.  Another example
> of posix braindeath -- how long before people realize that the
> thing branded 'posix' now isn't the real posix that was started
> to *describe* behaviors, not prescribe or proscribe behaviors.

Do you realize that this prompt expansion was in ksh since at least
ksh-86?  ksh-88 was one of the Posix base documents, and that
expansion was estabished behavior by the time Posix started its work.


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