base64: invalid input.

[Hongyi Zhao]

Hi all,

I do base64 decodeing by using the following command:

$ curl -s http://www.vpngate.net/api/iphone/ |
grep '^vpn' |
head -1 |
while IFS=, read -ra line; do
printf ${line[14]}| dos2unix |base64 -d
done
[...]
base64: invalid input

While the following one works more robust, i.e., will not give the last
line like this: ``base64: invalid input'',

$ curl -s http://www.vpngate.net/api/iphone/ |
grep '^vpn' | head -1 |
while IFS=, read -ra line; do
echo ${line[14]}| dos2unix |base64 -d ;
done
[...]

In the above two commands, the only different is the printf and echo
commands used for each of them.

So, why the first one will give the message: ``base64: invalid input'',
while the second one will be ok?

Regards
--
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.

[Dave Sines]

Hongyi Zhao <hongy...@gmail.com> wrote:
> Hi all,
>
> I do base64 decodeing by using the following command:

> printf ${line[14]}| dos2unix |base64 -d

printf '%s\n' "${line[14]}" | dos2unix | base64 -d

> base64: invalid input
>
> While the following one works more robust, i.e., will not give the last
> line like this: ``base64: invalid input'',

> echo ${line[14]}| dos2unix |base64 -d ;

> In the above two commands, the only different is the printf and echo
> commands used for each of them.
>
> So, why the first one will give the message: ``base64: invalid input'',
> while the second one will be ok?

echo appends a newline to its output, printf doesn't.

[Hongyi Zhao]

On Sat, 24 Oct 2015 13:21:45 +0100, Dave Sines wrote:

> printf '%s\n' "${line[14]}" | dos2unix | base64 -d

Ok, thanks, now, I use the awk to do this when echo command is used:

curl -s http://130.158.6.81/api/iphone/|
awk -F, '/^vpn/{ system( "echo "$NF"| dos2unix |base64 -d " ) }'

But, how to use the command ` printf '%s\n' ' in the awk's system()
funtion?

I've tried as follows:

curl --max-time 60 -s http://130.158.6.81/api/iphone/|
awk -F, '/^vpn/{ system( "printf '%s\n' "$NF"| base64 -d " ) }'

But, still, I'll obtain the ``base64: invalid input'' error messages.

[Janis Papanagnou]

On 24.10.2015 15:30, Hongyi Zhao wrote:
> On Sat, 24 Oct 2015 13:21:45 +0100, Dave Sines wrote:
>
>> printf '%s\n' "${line[14]}" | dos2unix | base64 -d
>
> Ok, thanks, now, I use the awk to do this when echo command is used:
>
> curl -s http://130.158.6.81/api/iphone/|
> awk -F, '/^vpn/{ system( "echo "$NF"| dos2unix |base64 -d " ) }'
>
> But, how to use the command ` printf '%s\n' ' in the awk's system()
> funtion?

Try using awk's printf instead of using system() resp. a shell...

awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'


Janis

[Hongyi Zhao]

On Sat, 24 Oct 2015 16:00:49 +0200, Janis Papanagnou wrote:

> Try using awk's printf instead of using system() resp. a shell...
>
> awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'

Tried the following, but still failed:

$ curl -s http://130.158.6.81/api/iphone/| awk -F',' '/^vpn/ { printf "%
s", $NF | "base64 -d" }'
shell-init: error retrieving current directory: getcwd: cannot access
parent directories: No such file or directory
[...]
base64: invalid input
awk: cmd. line:1: (FILENAME=- FNR=5) fatal: printf to "base64 -d" failed
(Broken pipe)

Regards

>
>
> Janis

[Thomas 'PointedEars' Lahn]

Hongyi Zhao wrote:

> $ curl -s http://www.vpngate.net/api/iphone/ |
> grep '^vpn' |
> head -1 |
> while IFS=, read -ra line; do
> printf ${line[14]}| dos2unix |base64 -d
> done
> [...]
> base64: invalid input
>
> While the following one works more robust, i.e., will not give the last
> line like this: ``base64: invalid input'',
>
> $ curl -s http://www.vpngate.net/api/iphone/ |
> grep '^vpn' | head -1 |
> while IFS=, read -ra line; do
> echo ${line[14]}| dos2unix |base64 -d ;
> done
> [...]
>
> In the above two commands, the only different is the printf and echo
> commands used for each of them.
>
> So, why the first one will give the message: ``base64: invalid input'',
> while the second one will be ok?

Obviously, something is different in the output of “dos2unix” that is piped
into base64(1). You do know what debugging is, yes?

--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Janis Papanagnou wrote:

> On 24.10.2015 15:30, Hongyi Zhao wrote:
>> On Sat, 24 Oct 2015 13:21:45 +0100, Dave Sines wrote:
>>> printf '%s\n' "${line[14]}" | dos2unix | base64 -d
>>
>> Ok, thanks, now, I use the awk to do this when echo command is used:

What is *your* problem? What in the universe makes you *not* to try first
the simpler solution just suggested to you?

>> curl -s http://130.158.6.81/api/iphone/|
>> awk -F, '/^vpn/{ system( "echo "$NF"| dos2unix |base64 -d " ) }'
>>
>> But, how to use the command ` printf '%s\n' ' in the awk's system()
>> funtion?
>
> Try using awk's printf instead of using system() resp. a shell...
>
> awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'

Hammer, nail. Obviously this inefficient overkill is not going to solve the
problem. (Determining the problem is that trivial that it is left as an
exercise to the reader for now.)

[Janis Papanagnou]

On 24.10.2015 16:40, Hongyi Zhao wrote:
> On Sat, 24 Oct 2015 16:00:49 +0200, Janis Papanagnou wrote:
>
>> Try using awk's printf instead of using system() resp. a shell...
>>
>> awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'
>
> Tried the following, but still failed:

If the encoded part is always terminated by a ^M then you can try this:

curl -s http://130.158.6.81/api/iphone/ |
awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'

(It works for me.)

Janis

[Janis Papanagnou]

On 24.10.2015 23:25, Thomas 'PointedEars' Lahn wrote:

> Janis Papanagnou wrote:
>
>> Try using awk's printf instead of using system() resp. a shell...
>>

>> awk -F, '/^vpn/ { printf "%s", $NF | "base64 -d" }'

(typo, missing -F, fixed)

>
> Hammer, nail. Obviously this inefficient overkill is not going to solve the
> problem. (Determining the problem is that trivial that it is left as an
> exercise to the reader for now.)
>

Using a text processor to extract only parts of only some selected records
and pass them to one single process to work on that seems efficient and to
the point. - Why do you think this method is inefficient? Or even overkill?

Janis

[Thomas 'PointedEars' Lahn]

To begin with, it is not equivalent to the original approach, which takes
the curl(1) output, and processes only the *first* occurrence (“grep … |
head -1”) of “vpn” on the beginning of a line (“^”). By contrast, your awk
program processes *all* lines that begin with “vpn”.

Second, if you apply the awk(1) solution to what is already there, you would
be executing awk in a subshell (thanks to the pipe), then run base64(1) in a
shell (“"…"”) from awk only to do what the subshell could have done in the
first place.

Granted, usually “awk -F… '/…/ { … }' is probably more efficient than “grep
… | while IFS=… read; do … done”, but you have to see the whole picture.
Running awk this way on a single line (if you modified your awk program)
when IFS would do *is* inefficient overkill.

[Thomas 'PointedEars' Lahn]

Janis Papanagnou wrote:

> On 24.10.2015 16:40, Hongyi Zhao wrote:
>> On Sat, 24 Oct 2015 16:00:49 +0200, Janis Papanagnou wrote:
>>> Try using awk's printf instead of using system() resp. a shell...
>>>
>>> awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'
>>
>> Tried the following, but still failed:
>
> If the encoded part is always terminated by a ^M then you can try this:
>
> curl -s http://130.158.6.81/api/iphone/ |
> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>
> (It works for me.)

By coincidence. It is not equivalent to the original approach, only to
Hongyi’s new, flawed overkill one.

[Janis Papanagnou]

On 25.10.2015 08:00, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
>
>> On 24.10.2015 16:40, Hongyi Zhao wrote:
>>> On Sat, 24 Oct 2015 16:00:49 +0200, Janis Papanagnou wrote:
>>>> Try using awk's printf instead of using system() resp. a shell...
>>>>
>>>> awk '/^vpn/ { printf "%s", $NF | "base64 -d" }'
>>>
>>> Tried the following, but still failed:
>>
>> If the encoded part is always terminated by a ^M then you can try this:
>>
>> curl -s http://130.158.6.81/api/iphone/ |
>> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>>
>> (It works for me.)
>
> By coincidence. It is not equivalent to the original approach, only to
> Hongyi’s new, flawed overkill one.

An "original approach" is in H.'s postings not a reliable category, since
(as you seem to have previously also mentioned) you one can often not be
sure what the task is.

Janis

[Hongyi Zhao]

On Sun, 25 Oct 2015 06:08:32 +0100, Janis Papanagnou wrote:

> If the encoded part is always terminated by a ^M then you can try this:
>
> curl -s http://130.158.6.81/api/iphone/ |
> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>
> (It works for me.)

The files is a standard csv file, perhaps it is generated on Windows OS,
and so the line-terminators look this.

Thanks, I also tried the dos2unix immediately after the pipe:

curl -s http://130.158.6.81/api/iphone/ | dos2unix |

awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'

[Janis Papanagnou]

On 25.10.2015 07:58, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
>
>> On 24.10.2015 23:25, Thomas 'PointedEars' Lahn wrote:
>>> Janis Papanagnou wrote:
>>>> Try using awk's printf instead of using system() resp. a shell...
>>>>
>>>> awk -F, '/^vpn/ { printf "%s", $NF | "base64 -d" }'
>>
>> (typo, missing -F, fixed)
>>
>>> Hammer, nail. Obviously this inefficient overkill is not going to solve
>>> the problem. (Determining the problem is that trivial that it is left as
>>> an exercise to the reader for now.)
>>
>> Using a text processor to extract only parts of only some selected records
>> and pass them to one single process to work on that seems efficient and to
>> the point. - Why do you think this method is inefficient? Or even
>> overkill?
>
> To begin with, it is not equivalent to the original approach, which takes
> the curl(1) output, and processes only the *first* occurrence (“grep … |
> head -1”) of “vpn” on the beginning of a line (“^”). By contrast, your awk
> program processes *all* lines that begin with “vpn”.

I was responding to a posting where I don't see any grep.

>
> Second, if you apply the awk(1) solution to what is already there, you would
> be executing awk in a subshell (thanks to the pipe),

No, that depends on the shell. The shell I use, for example, ksh, will run
the final pipe process in the current shell.

> then run base64(1) in a shell (“"…"”)

Why do you think so? Hyongi's system() will create a shell instance, yes.
The pipe in awk-syntax will not; my understanding is that awk exec's the
process that is quoted after the pipe and opens a pipe communication
channel to that process. Do you disagree?

> from awk only to do what the subshell could have done in the
> first place.

(So I think your assumptions were wrong and thus your conclusions as well.)

>
> Granted, usually “awk -F… '/…/ { … }' is probably more efficient than “grep
> … | while IFS=… read; do … done”,

Not "usually"; it's generally more efficient. Shell loops are known to be
inperformant, specifically if compared to tools that loop natively.

> but you have to see the whole picture.
> Running awk this way on a single line (if you modified your awk program)
> when IFS would do *is* inefficient overkill.

No one was running awk on a single line in the posted example that I was
replying to.

Janis

[Janis Papanagnou]

On 25.10.2015 08:21, Hongyi Zhao wrote:
> On Sun, 25 Oct 2015 06:08:32 +0100, Janis Papanagnou wrote:
>
>> If the encoded part is always terminated by a ^M then you can try this:
>>
>> curl -s http://130.158.6.81/api/iphone/ |
>> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>>
>> (It works for me.)
>
> The files is a standard csv file, perhaps it is generated on Windows OS,
> and so the line-terminators look this.
>
> Thanks, I also tried the dos2unix immediately after the pipe:
>
> curl -s http://130.158.6.81/api/iphone/ | dos2unix |
> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'

That requires an additional process, one that seems unnecessary.
Anyway. Does one of the methods now work for you?

Janis

>
> Regards
>>
>> Janis
>
>
>
>
>

[Hongyi Zhao]

On Sun, 25 Oct 2015 08:36:18 +0100, Janis Papanagnou wrote:

>> curl -s http://130.158.6.81/api/iphone/ | dos2unix |
>> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>
> That requires an additional process, one that seems unnecessary.
> Anyway. Does one of the methods now work for you?

Yes, all of the following works for me:

$ curl -s http://130.158.6.81/api/iphone/ | dos2unix |
awk -F $',' '/^vpn/ { printf "%s", $NF | "base64 -d" }'

$ curl -s http://130.158.6.81/api/iphone/ | dos2unix |
awk -F',' '/^vpn/ { printf "%s", $NF | "base64 -d" }'

$ curl -s http://130.158.6.81/api/iphone/ |

awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'

$ curl -s http://130.158.6.81/api/iphone/ |
awk -F'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'

Considering the efficiency, I should use few processes, so the version
without using the dos2unix is more preferable.

Another issue, I noticed that you using the awk's field-separator like
the following just the ones I've posted above:

awk -F $'\r|,' ...

And I've tried with the following form:

awk -F'\r|,' ...

It seems they are equivalent in the ultimate obitained results. So, why
you use it like that?

[Thomas 'PointedEars' Lahn]

Janis Papanagnou wrote:

> On 25.10.2015 07:58, Thomas 'PointedEars' Lahn wrote:
>> Janis Papanagnou wrote:
>>> On 24.10.2015 23:25, Thomas 'PointedEars' Lahn wrote:
>>>> Janis Papanagnou wrote:
>>>>> Try using awk's printf instead of using system() resp. a shell...
>>>>>
>>>>> awk -F, '/^vpn/ { printf "%s", $NF | "base64 -d" }'
>>>
>>> (typo, missing -F, fixed)
>>>
>>>> Hammer, nail. Obviously this inefficient overkill is not going to
>>>> solve the problem. (Determining the problem is that trivial that it is
>>>> left as an exercise to the reader for now.)
>>>
>>> Using a text processor to extract only parts of only some selected
>>> records and pass them to one single process to work on that seems
>>> efficient and to the point. - Why do you think this method is
>>> inefficient? Or even overkill?
>>
>> To begin with, it is not equivalent to the original approach, which takes
>> the curl(1) output, and processes only the *first* occurrence (“grep … |
>> head -1”) of “vpn” on the beginning of a line (“^”). By contrast, your
>> awk program processes *all* lines that begin with “vpn”.
>
> I was responding to a posting where I don't see any grep.

Yes, AISB, you did not see the whole picture.

>> Second, if you apply the awk(1) solution to what is already there, you
>> would be executing awk in a subshell (thanks to the pipe),
>
> No, that depends on the shell. The shell I use, for example, ksh, will run
> the final pipe process in the current shell.

How did you get that idea?

,-[ksh93 manual]
|
| A pipeline is a sequence of one or more commands separated by |. The
| standard output of each command but the last is connected by a pipe(2) to
| the standard input of the next command. Each command, except possibly the
^^^^^^^^
| last, is run as a separate process; the shell waits for the last command
^^^^^^^^^^^^^^^^
| to terminate.

,-[bash 4.x manual]
|
| […]
| Each command in a pipeline is executed as a separate process (i.e., in a
^^^^^^^^^^^^^^^^
| subshell).
^^^^^^^^

>> then run base64(1) in a shell (“"…"”)
>
> Why do you think so?

You ripped the relevant parts apart. The sentence continues with “from
awk”.

> Hyongi's system() will create a shell instance, yes.

_Hongyi_

> The pipe in awk-syntax will not; my understanding is that awk exec's the
> process that is quoted after the pipe and opens a pipe communication
> channel to that process. Do you disagree?

Yes, I do.

<http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/awk.1?query=awk>

<http://manpages.debian.org/cgi-bin/man.cgi?query=awk&sektion=&apropos=0&manpath=Debian%207.0%20wheezy>

The description there is a big vague (I even almost overlooked “|cmd”), but
I think if you run the command this way a shell is required to separate the
arguments. The gawk manual has it explicitly:

<http://www.gnu.org/software/gawk/manual/html_node/Redirection.html#index-pipe_002c-output>
|
| print items | command
|
| It is possible to send output to another program through a pipe instead of
| into a file. This redirection opens a pipe to command, and writes the
| values of items through this pipe to another process created to execute
| command.
|
| The redirection argument “command” is actually an awk expression. Its
| value is converted to a string whose contents give the shell command to be
^^^^^^^^^^^^^
| run.

>> from awk only to do what the subshell could have done in the
>> first place.
>
> (So I think your assumptions were wrong and thus your conclusions as
> well.)

(Your logic is flawed: “Ex falso quodlibet” means that from wrong
assumptions can be concluded *anything* – wrong *and* correct statements.)

>> Granted, usually “awk -F… '/…/ { … }' is probably more efficient than
>> “grep … | while IFS=… read; do … done”,
>
> Not "usually"; it's generally more efficient.

Evidentially it is not.

> Shell loops are known to be inperformant, specifically if compared to
> tools that loop natively.

There is only one line to be processed here. One does not even need a loop.

>> but you have to see the whole picture.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> Running awk this way on a single line (if you modified your awk program)
>> when IFS would do *is* inefficient overkill.
>
> No one was running awk on a single line in the posted example that I was
> replying to.

I have marked the important part.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> Janis Papanagnou wrote:
>> The pipe in awk-syntax will not; my understanding is that awk exec's the
>> process that is quoted after the pipe and opens a pipe communication
>> channel to that process. Do you disagree?
>
> Yes, I do.
>
> <http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/awk.1?query=awk>
>
> <http://manpages.debian.org/cgi-bin/man.cgi?query=awk&sektion=&apropos=0&manpath=Debian%207.0%20wheezy>
>
> The description there is a big vague (I even almost overlooked “|cmd”),

a _bit_

> but […]

[Thomas 'PointedEars' Lahn]

One can read more carefully.

[Thomas 'PointedEars' Lahn]

Hongyi Zhao wrote:

> On Sun, 25 Oct 2015 08:36:18 +0100, Janis Papanagnou wrote:
>>> curl -s http://130.158.6.81/api/iphone/ | dos2unix |
>>> awk -F $'\r|,' '/^vpn/ { printf "%s", $(NF-1) | "base64 -d" }'
>>
>> That requires an additional process, one that seems unnecessary.
>> Anyway. Does one of the methods now work for you?
>
> Yes, all of the following works for me:

Again, by coincidence; *neither* is equivalent to what you started with.

And I still cannot see that you have done a proper analysis of the problem,
*why* it happened. Knowing the solutions should not be enough for you; you
should want to know *why* and *how* they work, so that you can avoid this
and similar problems in the future.

[Janis Papanagnou]

On 25.10.2015 13:06, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
>>
>> I was responding to a posting where I don't see any grep.
>
> Yes, AISB, you did not see the whole picture.

The question was using it without the head(1). There's no need to argument
with "big picture" if there's a concrete answer to a concrete question in
a concrete posting.

>
>>> Second, if you apply the awk(1) solution to what is already there, you
>>> would be executing awk in a subshell (thanks to the pipe),
>>
>> No, that depends on the shell. The shell I use, for example, ksh, will run
>> the final pipe process in the current shell.
>
> How did you get that idea?

ksh88 and ksh93 always behaved that way that the last process is run in the
same process as the executing shell. You can just test that to see it.

>
> ,-[ksh93 manual]
> |
> | A pipeline is a sequence of one or more commands separated by |. The
> | standard output of each command but the last is connected by a pipe(2) to
> | the standard input of the next command. Each command, except possibly the
> ^^^^^^^^

Here they *may* (not sure) refer to POSIX behaviour (or *may* refer to other
platforms like WinDOS). The description in The new Kornshell book is explitly
saying what I told. And ksh88/ksh93's behaviour can also be tested.

> | last, is run as a separate process; the shell waits for the last command
> ^^^^^^^^^^^^^^^^
> | to terminate.
>
> ,-[bash 4.x manual]

(Bash behaves differently, as may some-other-shell. I was speaking of ksh.)

> [...]

>
>>> then run base64(1) in a shell (“"…"”)
>>

>> The pipe in awk-syntax will not; my understanding is that awk exec's the
>> process that is quoted after the pipe and opens a pipe communication
>> channel to that process. Do you disagree?
>
> Yes, I do.

I stand corrected. The GNU documentation misleaded me where it says:

"This redirection opens a pipe to command, and writes the values of
items through this pipe to another process created to execute command."

Yes, I agree, awk seems to generate one shell instance for that.

>
> <http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/awk.1?query=awk>
>
> <http://manpages.debian.org/cgi-bin/man.cgi?query=awk&sektion=&apropos=0&manpath=Debian%207.0%20wheezy>
>
> The description there is a big vague (I even almost overlooked “|cmd”), but
> I think if you run the command this way a shell is required to separate the
> arguments.

I've simply checked with: awk '{ print | "cat | cat" }' or "nl | nl"

The inner pipe is not part of awk syntax, thus a shell instance necessary.

> The gawk manual has it explicitly:
>
> <http://www.gnu.org/software/gawk/manual/html_node/Redirection.html#index-pipe_002c-output>

[...]

> |
> | The redirection argument “command” is actually an awk expression. Its
> | value is converted to a string whose contents give the shell command to be
> ^^^^^^^^^^^^^
> | run.

I've overlooked that.

>
>>> Granted, usually “awk -F… '/…/ { … }' is probably more efficient than
>>> “grep … | while IFS=… read; do … done”,
>>
>> Not "usually"; it's generally more efficient.
>
> Evidentially it is not.

We can agree that we disagree here.

>
>> Shell loops are known to be inperformant, specifically if compared to
>> tools that loop natively.
>
> There is only one line to be processed here. One does not even need a loop.

If you process one line you need nothing but variable substitutions. But that
is a different case than the case that had been asked.

Janis

> [...]

[Janis Papanagnou]

On 25.10.2015 09:32, Hongyi Zhao wrote:
>
> Another issue, I noticed that you using the awk's field-separator like
> the following just the ones I've posted above:
>
> awk -F $'\r|,' ...
>
> And I've tried with the following form:
>
> awk -F'\r|,' ...
>
> It seems they are equivalent in the ultimate obitained results. So, why
> you use it like that?

The escape interpretation happens on different levels; use what fits best
in any given context.
The first is an ANSI string expanded by the shell. I prefer that to make
sure to know what the programs (here awk) get.
The second may or may not be interpreted by the programs. Awk obviously
interprets escaped characters.

Janis

[Janis Papanagnou]

On 25.10.2015 13:06, Thomas 'PointedEars' Lahn wrote:
>>

>> (So I think your assumptions were wrong and thus your conclusions as
>> well.)
>
> (Your logic is flawed:

Nope. Since you have obviously heard basic lecures about logic you may also
know what problems some logics have with *arbitrary* conclusions in practise.
Simply put; that's why there's e.g. paraconsistent logic to fit requirements
from reality.

> “Ex falso quodlibet” means that from wrong
> assumptions can be concluded *anything* – wrong *and* correct statements.)

This is a true statement. But here again you are assuming a specific logic;
IOW, this is a strawman argument.

Janis

[Hongyi Zhao]

On Sun, 25 Oct 2015 23:16:48 +0100, Janis Papanagnou wrote:

> The escape interpretation happens on different levels; use what fits
> best in any given context.
> The first is an ANSI string expanded by the shell. I prefer that to make
> sure to know what the programs (here awk) get.
> The second may or may not be interpreted by the programs. Awk obviously
> interprets escaped characters.

Thanks a lot for your explanation.

I've tried to search the manpage of bash or awk, but all of my tries
failed to find the above explanations given by you.

[Janis Papanagnou]

On 26.10.2015 03:24, Hongyi Zhao wrote:
> On Sun, 25 Oct 2015 23:16:48 +0100, Janis Papanagnou wrote:
>
>> The escape interpretation happens on different levels; use what fits
>> best in any given context.
>> The first is an ANSI string expanded by the shell. I prefer that to make
>> sure to know what the programs (here awk) get.
>> The second may or may not be interpreted by the programs. Awk obviously
>> interprets escaped characters.
>
> Thanks a lot for your explanation.
>
> I've tried to search the manpage of bash or awk, but all of my tries
> failed to find the above explanations given by you.

Details about the first can usually be found under the term "ANSI string".
In the bash man page you find it in the section about "Quoting":

Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded
as follows:
...

And the latter had not long ago been discussed in comp.lang.awk, but maybe
you can also find it documented in the GNU awk manual.

Janis

[Hongyi Zhao]

On Mon, 26 Oct 2015 06:51:58 +0100, Janis Papanagnou wrote:

> Details about the first can usually be found under the term "ANSI
> string".
> In the bash man page you find it in the section about "Quoting":
>
> Words of the form $'string' are treated specially. The word expands
> to string, with backslash-escaped characters replaced as specified by
> the ANSI C standard. Backslash escape sequences, if present, are
> decoded as follows:
> ...

The bash's manpage is so long -- about 5000+ lines, and I previously not
use the keyword $'string' to search in it and so cann't find the
corresponding paragraphs.

But, for a specific question, say for this, the idea itself of extract
the search key $'string' to search the bash's manpage is also difficult
to find.

>
> And the latter had not long ago been discussed in comp.lang.awk, but
> maybe you can also find it documented in the GNU awk manual.

Maybe, the appropriate keywords for searching the awk's manual is a key
for finding it. Just as the former.

Regards

[Thomas 'PointedEars' Lahn]

Janis Papanagnou wrote:

> On 25.10.2015 13:06, Thomas 'PointedEars' Lahn wrote:
>> Janis Papanagnou wrote:
>>> I was responding to a posting where I don't see any grep.
>> Yes, AISB, you did not see the whole picture.
>
> The question was using it without the head(1).

Nonsense. Hongyi, again not knowing what they were doing, went off a
tangent to completely disregard the good advice they were given regarding
the built-in/shell printf(1), and you, knowing only the hammer awk as a
tool, saw only a nail and were following them.

I might consider the rest of your posting later.

[Thomas 'PointedEars' Lahn]

Janis Papanagnou wrote:

> On 25.10.2015 13:06, Thomas 'PointedEars' Lahn wrote:
>>> (So I think your assumptions were wrong and thus your conclusions as
>>> well.)
>> (Your logic is flawed:
>
> Nope. Since you have obviously heard basic lecures about logic you may
> also know what problems some logics have with *arbitrary* conclusions in
> practise. Simply put; that's why there's e.g. paraconsistent logic to fit
> requirements from reality.

Not even wrong.

>> “Ex falso quodlibet” means that from wrong assumptions can be concluded
>> *anything* – wrong *and* correct statements.)
>
> This is a true statement. But here again you are assuming a specific
> logic;

There is only one logic in that context.

> IOW, this is a strawman argument.

No, it is not.

[Janis Papanagnou]

On 27.10.2015 00:38, Hongyi Zhao wrote:
> On Mon, 26 Oct 2015 06:51:58 +0100, Janis Papanagnou wrote:
>
>> Details about the first can usually be found under the term "ANSI
>> string".
>> In the bash man page you find it in the section about "Quoting":
>>
>> Words of the form $'string' are treated specially. The word expands
>> to string, with backslash-escaped characters replaced as specified by
>> the ANSI C standard. Backslash escape sequences, if present, are
>> decoded as follows:
>> ...
>
> The bash's manpage is so long -- about 5000+ lines, and I previously not
> use the keyword $'string' to search in it and so cann't find the
> corresponding paragraphs.
>
> But, for a specific question, say for this, the idea itself of extract
> the search key $'string' to search the bash's manpage is also difficult
> to find.

Searching the shell man pages for all those cryptic shell constructs is
indeed an issue. Just provided you the pointers because I accidentally
stumbled across those chapters.

Janis