I noticed the following example here [1]:

```
#!/bin/sh

if [ "$#" != "1" ]; then
echo "Usage: test.sh <string>"
exit 1
fi;

gap -r -b -q << EOI
LoadPackage( "CrystCat" );
DisplaySpaceGroupType( "$1" );
EOI
```

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

[1] https://stackoverflow.com/questions/13418849/how-can-i-call-gap-functions-from-a-shell-script

Regards,
HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/05/2022 07:31, [email protected] wrote:

I noticed the following example here [1]:

```
#!/bin/sh

if [ "$#" != "1" ]; then
echo "Usage: test.sh <string>"
exit 1
fi;

gap -r -b -q << EOI
LoadPackage( "CrystCat" );
DisplaySpaceGroupType( "$1" );
EOI
```

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

[1] https://stackoverflow.com/questions/13418849/how-can-i-call-gap-functions-from-a-shell-script

Regards,
HZ

Why not try [ $# -ne 1 ] ?

--
Chris Elvidge
England

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 May 2022 23:31:37 -0700, [email protected] wrote:

I noticed the following example here [1]:

```
#!/bin/sh

if [ "$#" != "1" ]; then
echo "Usage: test.sh <string>"
exit 1
fi;

gap -r -b -q << EOI LoadPackage( "CrystCat" );
DisplaySpaceGroupType( "$1" );
EOI ```

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

I see no /obvious/ reason.

On a (perhaps) related note, why did the author of that code snippet
use a string test rather than an an arithmetic test? To me, the
code snippet should read
if [ $# -ne 1 ]
then
echo 'Usage: test.sh <string>'
exit 1
fi

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11.05.2022 08:31, [email protected] wrote:

I noticed the following example here [1]:

```
#!/bin/sh

if [ "$#" != "1" ]; then
echo "Usage: test.sh <string>"
exit 1
fi;

gap -r -b -q << EOI
LoadPackage( "CrystCat" );
DisplaySpaceGroupType( "$1" );
EOI
```

Why did you post this here-doc code which is completely unrelated
to your question?

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

On Stackoverflow I experienced a couple of "experts" that spread
the wisdom of "always quote variable expansions"; this is fine as
a rule of thumb (but annoying if you know when you need quotes and
when not). This may have been the reason but is of course completely unnecessary.

Since the shebang line is qualifying '/bin/sh' the best answer (as
already suggested) is probably to use [ $# -ne 1 ]

Janis

[1] https://stackoverflow.com/questions/13418849/how-can-i-call-gap-functions-from-a-shell-script

Regards,
HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 10 May 2022 23:31:37 -0700 (PDT), "[email protected]" <[email protected]> wrote:

I noticed the following example here [1]:

```
#!/bin/sh
if [ "$#" != "1" ]; then
echo "Usage: test.sh <string>"
exit 1
fi;

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Both are possible. If they had written:
:: [ $# != 1 ]
you might have asked:
:: It seems that [ "$#" != "1" ] is enough.
:: Why use [ $# != 1 ] here?

Not surprisingly, there is even another way to do it:
:: [ $# -ne 1 ]

I hope this helps
--
Kees Nuyt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <t5g944$3ak$[email protected]>,
Lew Pitcher <[email protected]> wrote:
...

I see no /obvious/ reason.

On a (perhaps) related note, why did the author of that code snippet
use a string test rather than an an arithmetic test? To me, the
code snippet should read

Like you said above, there is no difference.

And there are about thousand other ways of doing it as well. Take your pick...

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Rorschach

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

--hymie! http://nasalinux.net/~hymie [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero, [email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid this problem?

[ $# -ne 1 ]

--hymie! http://nasalinux.net/~hymie [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.05.2022 03:35, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid this problem?

[ $# -ne 1 ]

$FOO is an arbitrary user defined (or undefined) variable.
$# is a numeric variable set by the shell.

So [ $FOO -ne 1 ] will not avoid the issue.

Of course just trying that code would be faster than writing a post.

--hymie! http://nasalinux.net/~hymie [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, May 12, 2022 at 9:53:39 AM UTC+8, Janis Papanagnou wrote:

On 12.05.2022 03:35, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid this problem?

[ $# -ne 1 ]

$FOO is an arbitrary user defined (or undefined) variable.
$# is a numeric variable set by the shell.

So [ $FOO -ne 1 ] will not avoid the issue.

Of course just trying that code would be faster than writing a post.

Yes. All the problems discussed in this post can be illustrated by the following examples:

$ [ "$FOO" = 1 ]; echo $?
1
$ [ "$FOO" = "1" ]; echo $?
1
$ [ $FOO -ne 1 ]
bash: [: -ne: unary operator expected
$ [ "$FOO" -ne 1 ]
bash: [: : integer expression expected

But maybe this way can also help others.

Best,
HZ

--hymie! http://nasalinux.net/~hymie [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 11 May 2022 18:35:24 -0700, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid
this problem?

[ $# -ne 1 ]

As a specific solution, yes.

$# is guaranteed to contain a numeric count of the number of arguments
passed into a script. It *cannot* be empty, or contain space delimited
values, so bracketing it in doublequotes is redundant. Both sides of the
test contain a decimal values, so a numeric test (such as -ne) would be appropriate.

OTOH, as a general solution, not so much.

In the test
[ $FOO -ne $BAR ]
neither $FOO nor $BAR provide the content guarantees that $# does (not
empty, not space delimited string, numeric value only) so it would be
prudent to bracket each with doublequotes. Also, given that neither
guarantees a numeric value, it would be prudent to use the != test
instead of the -ne test, making the /prudent/ test
[ "$FOO" != "$BAR" ]

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.05.2022 05:42, [email protected] wrote:

On Thursday, May 12, 2022 at 9:53:39 AM UTC+8, Janis Papanagnou wrote:

On 12.05.2022 03:35, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid this problem?

[ $# -ne 1 ]

$FOO is an arbitrary user defined (or undefined) variable.
$# is a numeric variable set by the shell.

So [ $FOO -ne 1 ] will not avoid the issue.

Of course just trying that code would be faster than writing a post.

Yes. All the problems discussed in this post can be illustrated by the following examples:

$ [ "$FOO" = 1 ]; echo $?
1
$ [ "$FOO" = "1" ]; echo $?
1
$ [ $FOO -ne 1 ]
bash: [: -ne: unary operator expected
$ [ "$FOO" -ne 1 ]
bash: [: : integer expression expected

In your thread you have asked a question about using the test command
and quoting to address some issues and, based on some sample code from
the net, understand how it works best. In this context it is noteworthy
that (for own programs) you have more (and better) choices. Some of the
issues and caveats that the historic test command and shell's command
syntax with test has (which unfortunately is also the only standard
base for standard shell) are fixed or alleviated with the test syntax
[[...]] that the powerful "modern" shells (ksh, bash, zsh, maybe others
too) support. (In this vein inspect for arithmetic contexts also the
arithmetic command ((...)) construct.)

I suggest to try these contemporary constructs with code samples like
the ones you started with above, vary the data from undefined, empty,
defined, defined with spaces, use of shell-patterns for comparisons,
use various comparison operators (!=, ==, =) etc., compare it with the
old (standard) syntax, and observe the difference in behavior, the
consistency, whether it meets your expectations, or whether one or the
other surprises you. Then draw your conclusions.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, May 13, 2022 at 6:59:15 AM UTC+8, Janis Papanagnou wrote:

On 12.05.2022 05:42, [email protected] wrote:

On Thursday, May 12, 2022 at 9:53:39 AM UTC+8, Janis Papanagnou wrote:

On 12.05.2022 03:35, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid this problem?

[ $# -ne 1 ]

$FOO is an arbitrary user defined (or undefined) variable.
$# is a numeric variable set by the shell.

So [ $FOO -ne 1 ] will not avoid the issue.

Of course just trying that code would be faster than writing a post.

Yes. All the problems discussed in this post can be illustrated by the following examples:

$ [ "$FOO" = 1 ]; echo $?
1
$ [ "$FOO" = "1" ]; echo $?
1
$ [ $FOO -ne 1 ]
bash: [: -ne: unary operator expected
$ [ "$FOO" -ne 1 ]
bash: [: : integer expression expected

In your thread you have asked a question about using the test command
and quoting to address some issues and, based on some sample code from
the net, understand how it works best. In this context it is noteworthy
that (for own programs) you have more (and better) choices. Some of the issues and caveats that the historic test command and shell's command
syntax with test has (which unfortunately is also the only standard
base for standard shell) are fixed or alleviated with the test syntax
[[...]] that the powerful "modern" shells (ksh, bash, zsh, maybe others
too) support. (In this vein inspect for arithmetic contexts also the arithmetic command ((...)) construct.)

I suggest to try these contemporary constructs with code samples like
the ones you started with above, vary the data from undefined, empty, defined, defined with spaces, use of shell-patterns for comparisons,
use various comparison operators (!=, ==, =) etc., compare it with the
old (standard) syntax, and observe the difference in behavior, the consistency, whether it meets your expectations, or whether one or the
other surprises you. Then draw your conclusions.

Thank you for your advice and suggestions.

Janis

HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, May 12, 2022 at 10:21:29 PM UTC+8, Lew Pitcher wrote:

On Wed, 11 May 2022 18:35:24 -0700, [email protected] wrote:

On Thursday, May 12, 2022 at 3:49:49 AM UTC+8, hymie! wrote:

In our last episode, the evil Dr. Lacto had captured our hero,
[email protected] <[email protected]>, who said:

I noticed the following example here [1]:

if [ "$#" != "1" ]; then

It seems that [ $# != 1 ] is enough. Why use [ "$#" != "1" ] here?

Consider a different variable

if [ $FOO != 1 ] ; then

if $FOO is completely uninitialized, then this will expand to

if [ != 1 ] ; then

which is a syntax error.

That is the reason that I, personally, almost always use the extra
quotation marks.

As commented by others in this thread, the following method will avoid
this problem?

[ $# -ne 1 ]

As a specific solution, yes.

$# is guaranteed to contain a numeric count of the number of arguments
passed into a script. It *cannot* be empty, or contain space delimited values, so bracketing it in doublequotes is redundant. Both sides of the
test contain a decimal values, so a numeric test (such as -ne) would be appropriate.

OTOH, as a general solution, not so much.

In the test
[ $FOO -ne $BAR ]
neither $FOO nor $BAR provide the content guarantees that $# does (not
empty, not space delimited string, numeric value only) so it would be
prudent to bracket each with doublequotes. Also, given that neither guarantees a numeric value, it would be prudent to use the != test
instead of the -ne test, making the /prudent/ test
[ "$FOO" != "$BAR" ]

Thank you for your prudent analysis.

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lew Pitcher wrote:

$# is guaranteed to contain a numeric count of the number of arguments
passed into a script. It *cannot* be empty, or contain space delimited values, so bracketing it in doublequotes is redundant.

Double quotes around $# are redundant only if there are no digits in IFS.

That would certainly be true for the case the OP asked about, where the
$# expansion was in the first command executed in the script. But it
can't be assumed to be true in general.

--
Geoff Clare <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 May 2022 13:21:52 +0100, Geoff Clare wrote:

Lew Pitcher wrote:

$# is guaranteed to contain a numeric count of the number of arguments
passed into a script. It *cannot* be empty, or contain space delimited
values, so bracketing it in doublequotes is redundant.

Double quotes around $# are redundant only if there are no digits in
IFS.

Good catch!

That would certainly be true for the case the OP asked about, where the
$# expansion was in the first command executed in the script. But it
can't be assumed to be true in general.

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-05-13, Geoff Clare <[email protected]d> wrote:

Lew Pitcher wrote:

$# is guaranteed to contain a numeric count of the number of arguments
passed into a script. It *cannot* be empty, or contain space delimited
values, so bracketing it in doublequotes is redundant.

Double quotes around $# are redundant only if there are no digits in IFS.

That would certainly be true for the case the OP asked about, where the
$# expansion was in the first command executed in the script. But it
can't be assumed to be true in general.

IFS is analogous to an important environmental register in a machine
language ABI, such as a global offset pointer register. Code which wants
to manipulate it must save the value, and restore it not only when it
is done, but around calls to any other code.

The onus is on whoever introduces IFS manipulation to do the above,
and in general to debug their shit. We'd never blame a piece of shell
code which does a naked $# expansion for a breakage caused by an altered
IFS; the IFS alteration is to blame.

If you're writing code with unknown callers for general use, you should cheerfully assume that the normal IFS is in effect, and not do any
obviously unnecessary quoting.

Only code which is specifically a helper routine to some
IFS-manpipulating code (like being part of the same module) has any
reason to defend against the changed IFS.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, May 13, 2022 at 8:41:08 PM UTC+8, Geoff Clare wrote:

Lew Pitcher wrote:

$# is guaranteed to contain a numeric count of the number of arguments passed into a script. It *cannot* be empty, or contain space delimited values, so bracketing it in doublequotes is redundant.

Double quotes around $# are redundant only if there are no digits in IFS.

It's empty on my machine (Ubuntu 20.04.3 LTS):

$ echo $IFS

$

That would certainly be true for the case the OP asked about, where the
$# expansion was in the first command executed in the script. But it
can't be assumed to be true in general.

--
Geoff Clare <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 May 2022 22:15:41 -0700 (PDT), "[email protected]" <[email protected]> wrote:

It's empty on my machine (Ubuntu 20.04.3 LTS):

$ echo $IFS

$

No, it isn't empty. The characters it contains just do not leave
ink on your canvas.

user@host:~ $ printf '>%s<' "$IFS"|hexdump -C
00000000 3e 20 09 0a 3c |> ..<|
00000005
--
Kees Nuyt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, May 15, 2022 at 4:57:34 PM UTC+8, Kees Nuyt wrote:

On Sat, 14 May 2022 22:15:41 -0700 (PDT), "[email protected]" <[email protected]> wrote:

It's empty on my machine (Ubuntu 20.04.3 LTS):

$ echo $IFS

$

No, it isn't empty. The characters it contains just do not leave
ink on your canvas.

user@host:~ $ printf '>%s<' "$IFS"|hexdump -C
00000000 3e 20 09 0a 3c |> ..<|
00000005

I get the following using od:

$ printf '>%s<' "$IFS"| od -xc --endian=big
0000000 3e20 090a 3c00
> \t \n <
0000005

Why aren't they exactly the same?

HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.05.2022 15:31, [email protected] wrote:

On Sunday, May 15, 2022 at 4:57:34 PM UTC+8, Kees Nuyt wrote:

On Sat, 14 May 2022 22:15:41 -0700 (PDT), "[email protected]"
<[email protected]> wrote:

It's empty on my machine (Ubuntu 20.04.3 LTS):

$ echo $IFS

$

No, it isn't empty. The characters it contains just do not leave
ink on your canvas.

user@host:~ $ printf '>%s<' "$IFS"|hexdump -C
00000000 3e 20 09 0a 3c |> ..<|
00000005

I get the following using od:

$ printf '>%s<' "$IFS"| od -xc --endian=big
0000000 3e20 090a 3c00
> \t \n <
0000005

Why aren't they exactly the same?

The output isn't the same because you used a different program.

The IFS value is the same. Of course the unnecessary > and < will
distract you from the IFS dedails in the od/hexdump output. Keep
it simple

$ printf '%s' "$IFS" | od -t x1
0000000 20 09 0a

That's a Blank, a Tab, and a Newline.

Janis

HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, May 15, 2022 at 9:58:36 PM UTC+8, Janis Papanagnou wrote:

On 15.05.2022 15:31, [email protected] wrote:

On Sunday, May 15, 2022 at 4:57:34 PM UTC+8, Kees Nuyt wrote:

On Sat, 14 May 2022 22:15:41 -0700 (PDT), "[email protected]"
<[email protected]> wrote:

It's empty on my machine (Ubuntu 20.04.3 LTS):

$ echo $IFS

$

No, it isn't empty. The characters it contains just do not leave
ink on your canvas.

user@host:~ $ printf '>%s<' "$IFS"|hexdump -C
00000000 3e 20 09 0a 3c |> ..<|
00000005

I get the following using od:

$ printf '>%s<' "$IFS"| od -xc --endian=big
0000000 3e20 090a 3c00

\t \n <

0000005

Why aren't they exactly the same?

The output isn't the same because you used a different program.

The IFS value is the same. Of course the unnecessary > and < will
distract you from the IFS dedails in the od/hexdump output. Keep
it simple

$ printf '%s' "$IFS" | od -t x1
0000000 20 09 0a

That's a Blank, a Tab, and a Newline.

I checked them with the following command:

$ ascii -t 0x20 0x09 0x0a
2/0 32 0x20 0o40 00100000
0/9 9 0x09 0o11 00001001
0/10 10 0x0A 0o12 00001010

How to retrieve the character names at the same time?

HZ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 16 May 2022 02:00:27 -0700 (PDT), "[email protected]" <[email protected]> wrote:

I checked them with the following command:

$ ascii -t 0x20 0x09 0x0a
2/0 32 0x20 0o40 00100000
0/9 9 0x09 0o11 00001001
0/10 10 0x0A 0o12 00001010

How to retrieve the character names at the same time?

1: Explore the options in 'man -s 1 ascii' and try
ascii -a 0xHH ...
plus a bit of awk code

2: You don't have to, because from experience you know
0x20 is space, 0x09 is TAB and 0x0A is linefeed

3: Use the lookup table in 'man -s 7 ascii'

You just failed the quiz.
--
Kees Nuyt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, May 16, 2022 at 5:29:42 PM UTC+8, Kees Nuyt wrote:

On Mon, 16 May 2022 02:00:27 -0700 (PDT), "[email protected]" <[email protected]> wrote:

I checked them with the following command:

$ ascii -t 0x20 0x09 0x0a
2/0 32 0x20 0o40 00100000
0/9 9 0x09 0o11 00001001
0/10 10 0x0A 0o12 00001010

How to retrieve the character names at the same time?

1: Explore the options in 'man -s 1 ascii' and try
ascii -a 0xHH ...
plus a bit of awk code

$ echo "0x20 0x09 0x0a" | xargs -n1 ascii -a|grep names
Other names: Space, Blank
Other names: Horizontal Tab, \t
Other names: Newline, \n

2: You don't have to, because from experience you know
0x20 is space, 0x09 is TAB and 0x0A is linefeed

3: Use the lookup table in 'man -s 7 ascii'

You just failed the quiz.
--
Kees Nuyt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)