Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.unix.shell
Subject: Re: bash aesthetics question: special characters in reg exp in [[
 ... =~~ ... ]]
Date: Tue, 23 Jul 2024 18:20:14 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <20240723110919.974@kylheku.com>
References: <v7mknf$3plab$1@news.xmission.com>
 <20240722153843.823@kylheku.com> <v7nu8t$15bon$1@dont-email.me>
Injection-Date: Tue, 23 Jul 2024 20:20:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2e723cea1cdfb5e1d326eb8834436c3e";
	logging-data="1392005"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/OUPAJozVbpK1nJZ1sF/f40VumndLRf1c="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:ixfy+jOnXV/+qQk9ytCHj9xqFh8=
Bytes: 3718

On 2024-07-23, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 23.07.2024 00:47, Kaz Kylheku wrote:
>> On 2024-07-22, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> The problem is that if the above is in a function, when you list out the
>>> function with "type funName", the \n has already been digested and
>>> converted to a hard newline.  This makes the listing look strange.  I'd
>>> rather see "\n".
>> 
>> I see what you mean:
>> 
>> $ test() {  [[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar" ; }
>> $ set | grep -A 4 '^test'
>> test ()
>> {
>>     [[ "$f" =~ foo[^'
>> ']*bar ]] && echo "foo bar"
>> }
>> 
>>> Is there any way to get this?
>
> Of course (and out of curiosity) I tried that display detail as well
> in Kornshell to see how it behaves, and using a different command to
> display it...
>
>
> With my (old?) bash:
>
> $ f() {  [[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar" ; }
> $ typeset -f f
> f ()
> {
>     [[ "$f" =~ foo[^'
> ']*bar ]] && echo "foo bar"
> }
>
>
> The same with ksh:
>
> $ f() {  [[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar" ; }
> $ typeset -f f
> f() {  [[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar" ; }
>
>
> And for good measure also in zsh:
>
> % f() {  [[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar" ; }
> % typeset -f f
> f () {
> 	[[ "$f" =~ foo[^$'\n']*bar ]] && echo "foo bar"
> }

It bolsters the argument that Bash could use a fix to be this
way also.

zsh preserves the original syntax. So it is saving information
in the stored code about how the datum was represented in
the source code:

  % f() {  [[ "$f" =~ foo[^'
  ']*bar ]] && echo "foo bar" ; }
  sun-go% typeset -f f
  f () {
	  [[ "$f" =~ foo[^'
  ']*bar ]] && echo "foo bar"
  }

I can understand why an implementor wouldn't want to save this.

If the code that we see in "typeset" is the actual code that
executes, it means that in the $'...' case, zsh has to process
the escape sequences, whereas bash has expanded them out upfront.

If the code that we see in "typeset" is not the actual code
that executes, then that requires extra storage. The Bash
project might be reluctant to imitate that strategy.

Oh look, zsh preserves comments:

  sun-go% f() { # f function
  function> :
  function> }
  sun-go% typeset -f f
  f () {
	  # f function
	  :
  }

I doubt that when f is called, it's actually dealing with the
lexical details any more like comments; it's storing some
compiled version of the code along with the source, more likely.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca