Re: consistency probs var & function re-use

[Greg Wooledge]

On Sun, Jun 11, 2017 at 03:51:26PM -0700, L A Walsh wrote:
> I was pointing out that the reason 'declare' used a newline, was that he
> had not quoted the input to 'x', which is expanded to a newline
> before it is assigned to 'x'.

You are completely wrong here.  My variable 'x' had a newline in its
content.  I used the $'...' quoting syntax to enter it as such.

Your variable did not have a newline in it, because you used "..."
quoting.

The result of declare -p x is a bash command that you can eval (or
source) to recreate the variable x with the same content and attributes.
(But not scope, of course.  It doesn't encode scope information.)

Bash is free to use a different kind of quoting around the variable
content in declare -p's output.  I don't care that bash chooses a
different formatting than I used.  The end result is the same variable,
so it simply doesn't matter.

>   hh(){ echo "hi"; }
> which gets printed out as:
> 
>  declare -f hh
>  hh ()
>  {
>  echo "hi"
>  }

But it's the *same function*.  It's just got different formatting.
Given the same arguments, both of them execute the same commands.
This is the definition of reusability that we're working with.

Does it reproduce your exact formatting?  No.  It's not intended to.
In fact, some people *like* it this way.  It's a pretty-printer for
functions.

> I.e. it wasn't that I wanted to embed newlines in the function, but that
> I wanted it to print out the same way it was input.

Then store it in a file and source that file every time you want to use
it.  If you want to see your gorgeous whitespace formatting, cat the file.

declare -fp is not a guarantee of whitespace preservation.  It's merely
a guarantee that the resulting function works the same way.

Re: consistency probs var & function re-use

[L A Walsh]

Charles Daffern wrote:

   First problem: If you are assigning a string to a variable,
you need to put quotes around the string.  That shows that "-p"
doesn't insert newlines:

 > x="$'foo\nbar'"
 > declare -p x
 declare -- x="\$'foo\\nbar'"



You do not have any newlines in that string, so of course the
demonstration with -p will show no newlines.
  

Right.  you should be addressing your comment to 'Greg Wooledge',
who said:

   Are you allergic to newlines?  declare -p uses raw newlines in its output
   whenever it feels they are appropriate.  Even in ordinary shell variables:

   imadev:~$ x=$'foo\nbar'
   imadev:~$ declare -p x
   declare -- x="foo
   bar"

 


--

I was pointing out that the reason 'declare' used a newline, was that he
had not quoted the input to 'x', which is expanded to a newline
before it is assigned to 'x'.

Or did you miss that post?
  
What are you trying to do? 
  

Read var & func defs via a 'read' of 1 line.



In your variable "x" above, you have encoded the string in a format
which contains no raw newlines and which can be "eval"ed to produce the
original contents.
Why don't you encode the function the same way?
  

I didn't encode the newline above, Greg did.

I used a format with NO newlines:

  hh(){ echo "hi"; }
which gets printed out as:

 declare -f hh
 hh ()
 {
 echo "hi"
 }


I.e. it wasn't that I wanted to embed newlines in the function, but that
I wanted it to print out the same way it was input.

Re: consistency probs var & function re-use

[L A Walsh]

Chet Ramey wrote:


 You are misunderstanding what that is supposed to do, or ignoring it.
 `declare -p' quotes its output in a way that allows it to be reused as
 shell input. Executing the output of `declare -p' will recreate the
 variable with an identical value.


Re-use as shell input?  That's a bit vague.  As the right-hand
expression for an assignment? or something one reads in?
There are plenty of examples that could qualify as being "shell input"
that don't work:


exec of output:

   > x=$'foo\nbar'
   > exec $(declare -p x)
   bash: exec: declare: not found


Assign & exec w/ quotes:

   > a=$(declare -p x)
   > exec "$a"
   bash: exec: declare -- x="foo
   bar": not found


Assign&exec w/o quotes:

   > exec $a
   bash: exec: declare: not found


Assign & try direct interpretation of value:

   > $a
   bash: declare: `bar"': not a valid identifier

Same w/quoteS:

   > "$a"
   bash: $'declare -- x="foo\nbar"': command not found


Reading output:

   > declare -p x|while read def; do
   > echo "def=$def"
   > done
   def=declare -- x="foo
   def=bar"

Reading it via proc-subst:

   > read a< <(declare -p x)
   Ishtar:law> echo "$a"
   declare -- x="foo

(I'm running out of ideas)...

It's not very easy to discern what you mean.  I'm sure
it is easy for someone who already knows the answer --
trivial even, but what type of bash-input are you referring to?

Re: consistency probs var & function re-use

[Chet Ramey]

On 6/11/17 5:57 PM, L A Walsh wrote:
> 
> 
> Chris F.A. Johnson wrote:
>> On Fri, 9 Jun 2017, L A Walsh wrote:
>>> 
>>>   First problem: If you are assigning a string to a variable,
>>> you need to put quotes around the string.
>>
>>You don't need to quote it unless it contains literal whitespace.
> ---
>Not true if you want to reproduce the string as output by
> "declare".  Since declare doesn't output the literal value in a
> variable, but an expanded one, you need to put quotes around any
> var that you intend to expand with 'declare'.
> 
> Greg's example:
> 
>   imadev:~$ x=$'foo\nbar'
>   imadev:~$ declare -p x
>   declare -- x="foo
>   bar"
> 
> Shows that "declare" isn't quoting its output such that it can be used for
> assignment to a var, or as 'read' input.

You are misunderstanding what that is supposed to do, or ignoring it.
`declare -p' quotes its output in a way that allows it to be reused as
shell input. Executing the output of `declare -p' will recreate the
variable with an identical value.

-- 
``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: consistency probs var & function re-use

[L A Walsh]

Chris F.A. Johnson wrote:

On Fri, 9 Jun 2017, L A Walsh wrote:


  First problem: If you are assigning a string to a variable,
you need to put quotes around the string.


   You don't need to quote it unless it contains literal whitespace.

---
   Not true if you want to reproduce the string as output by
"declare".  Since declare doesn't output the literal value in a
variable, but an expanded one, you need to put quotes around any
var that you intend to expand with 'declare'.

Greg's example:

  imadev:~$ x=$'foo\nbar'
  imadev:~$ declare -p x
  declare -- x="foo
  bar"

Shows that "declare" isn't quoting its output such that it can be 
used for assignment to a var, or as 'read' input.


To do that, you can use "printf %q" -- as in:

 x=$'foo\nbar'
 printf -v qx "%q" "$x"
 printf "%s\n" "$qx"
 $'foo\nbar'

I used double quotes around the original:

 x="$'foo\nbar'"

Which gives:

 printf "%s\n" "$x"
 $'foo\nbar'

The exact same output.

I.e. you need to double quote Greg's input for it to be re-usable as input.

Re: consistency probs var & function re-use

[L A Walsh]

Chris F.A. Johnson wrote:


A newline IS literal whitespace.

I'm glad you think so.  I tend to agree, but I was clarifying for
those that might have a different definition.

Re: consistency probs var & function re-use

[Charles Daffern]

>First problem: If you are assigning a string to a variable,
> you need to put quotes around the string.  That shows that "-p"
> doesn't insert newlines:
> 
>  > x="$'foo\nbar'"
>  > declare -p x
>  declare -- x="\$'foo\\nbar'"

You do not have any newlines in that string, so of course the
demonstration with -p will show no newlines.

>> What are you trying to do? 
> Read var & func defs via a 'read' of 1 line.

In your variable "x" above, you have encoded the string in a format
which contains no raw newlines and which can be "eval"ed to produce the
original contents.
Why don't you encode the function the same way?




signature.asc
Description: OpenPGP digital signature

Re: consistency probs var & function re-use

[Chris F.A. Johnson]

On Fri, 9 Jun 2017, L A Walsh wrote:


Chris F.A. Johnson wrote:

On Fri, 9 Jun 2017, L A Walsh wrote:


  First problem: If you are assigning a string to a variable,
you need to put quotes around the string.


   You don't need to quote it unless it contains literal whitespace.

Not exactly true -- "any" type of white space, including newlines, which
was the case in Greg's example.


A newline IS literal whitespace.

--
Chris F.A. Johnson, 

Re: consistency probs var & function re-use

[Chris F.A. Johnson]

On Fri, 9 Jun 2017, L A Walsh wrote:


Chris F.A. Johnson wrote:

On Fri, 9 Jun 2017, L A Walsh wrote:


  First problem: If you are assigning a string to a variable,
you need to put quotes around the string.


   You don't need to quote it unless it contains literal whitespace.

Not exactly true -- "any" type of white space, including newlines, which
was the case in Greg's example.


   A newline IS literal whitespace.

--
Chris F.A. Johnson, 

Re: consistency probs var & function re-use

[L A Walsh]

Chris F.A. Johnson wrote:

On Fri, 9 Jun 2017, L A Walsh wrote:


  First problem: If you are assigning a string to a variable,
you need to put quotes around the string.


   You don't need to quote it unless it contains literal whitespace.

Not exactly true -- "any" type of white space, including newlines, which
was the case in Greg's example.

Re: consistency probs var & function re-use

[Chris F.A. Johnson]

On Fri, 9 Jun 2017, L A Walsh wrote:


  First problem: If you are assigning a string to a variable,
you need to put quotes around the string.


   You don't need to quote it unless it contains literal whitespace.

--
Chris F.A. Johnson, 

Re: consistency probs var & function re-use

[L A Walsh]

Greg Wooledge wrote:

What are you talking about? Consistency between what two things?
Are you allergic to newlines? declare -p uses raw newlines in its output
whenever it feels they are appropriate. Even in ordinary shell variables:

imadev:~$ x=$'foo\nbar'
imadev:~$ declare -p x
declare -- x="foo
bar"

Is that "consistent" enough for you?


   First problem: If you are assigning a string to a variable,
you need to put quotes around the string.  That shows that "-p"
doesn't insert newlines:

 > x="$'foo\nbar'"
 > declare -p x
 declare -- x="\$'foo\\nbar'"

   However, if that is your example showing dcl-p's rule for inserting
newlines, then given this funcdef:

  hh(){ echo "hi";}

There shouldn't be any newlines (only inserting them when user
inserted a newline via $'\n').  However, in bash's output of
that function:

 > alias my=declare pf='my -pf'
 > pf hh
 hh ()
 {
 echo "hi"
 }
---
Oops... superfluous newlines were added :-(



Remember, a newline only takes 1 byte of memory.

The output is reusable, but only if you actually use it correctly. E.g.
stuff it into a variable and use eval "$myvar" with the double quotes.
Or redirect it into a file and use source ./myfile.

What are you trying to do? 

Read var & func defs via a 'read' of 1 line.

What did you try? 

 x="$'foo\nbar'"
 read -r mydef< <(declare -p x)
 echo "$mydef"

 hh(){ echo hi;}
 read -r mydef< <(declare -pf hh)
 echo "$mydef"


What happened? 

1st case worked:
declare -- x="\$'foo\nbar'"

2nd case didn't:
hh ()


What did you expect to happen instead?

If there was a consistency, then would have expected both to work.