Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is it possiable to comment out some args when writting them on multi-lines mode?

49 views
Skip to first unread message

Hongyi Zhao

unread,
Mar 19, 2015, 7:50:29 PM3/19/15
to
Hi all,

See the following usage for a specific tool, say, dig:

dig --arg1 \
--arg2 \
--arg3 \
...
<target>

In this case, if I want to comment out the --arg2, then I try the
following in my script to invoking dig but failed:


dig --arg1 \
# --arg2 \
--arg3 \
...
<target>

So, is it possiable to comment out some args when writting them on multi-
lines mode?

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

Kaz Kylheku

unread,
Mar 19, 2015, 8:30:56 PM3/19/15
to
On 2015-03-19, Hongyi Zhao <hongy...@gmail.com> wrote:
> dig --arg1 \
> # --arg2 \
> --arg3 \
> ...
> <target>
>
> So, is it possiable to comment out some args when writting them on multi-
> lines mode?

Idea:

ign()
{
:
}

dig --arg1 \
$(ign --arg2) \
--arg3

Janis Papanagnou

unread,
Mar 19, 2015, 8:55:57 PM3/19/15
to
Hehehe! A nice take on the issue. But why not just

dig --arg1 \
$(: --arg2) \
--arg3


Janis

Kaz Kylheku

unread,
Mar 19, 2015, 9:06:30 PM3/19/15
to
That's better. Leave the functions for things you can turn on and
off remotely.

./configure --arg1 \
$(CONFIG_CROSSCOMPILE --sysroot=...) \
--arg3

Or whatever.

Hongyi Zhao

unread,
Mar 19, 2015, 10:05:16 PM3/19/15
to
On Fri, 20 Mar 2015 01:55:51 +0100, Janis Papanagnou wrote:

> dig --arg1 \
> $(: --arg2) \
> --arg3

Still not so clear how to adapt for my case, say, the following command:


nmap -T4 \
--min-hostgroup 500 \
--min-parallelism 5000 \
--max-retries 1 \
--host-timeout 60 \
<target>


If I want to commented out the `--max-retries 1', then how should I
revise it based on your above method?

Janis Papanagnou

unread,
Mar 19, 2015, 11:01:00 PM3/19/15
to
Am 20.03.2015 um 03:05 schrieb Hongyi Zhao:
> On Fri, 20 Mar 2015 01:55:51 +0100, Janis Papanagnou wrote:
>
>> dig --arg1 \
>> $(: --arg2) \
>> --arg3
>
> Still not so clear how to adapt for my case, say, the following command:
>
>
> nmap -T4 \
> --min-hostgroup 500 \
> --min-parallelism 5000 \
> --max-retries 1 \
> --host-timeout 60 \
> <target>
>
>
> If I want to commented out the `--max-retries 1', then how should I
> revise it based on your above method?

You would put $(: and ) around the respective option settings:

$(: --max-retries 1 ) \

But, to be honest, this is fancy but I don't think this is a good idea,
since you'd have to make changes at two places in the considered lines.


My (serious) approach would probably go into another direction; like

MAX_RETRIES="--max-retries 1"
# and similar definitions with other options
#
nmap -T4 \
--min-hostgroup 500 \
--min-parallelism 5000 \
${MAX_RETRIES} \
--host-timeout 60 \
<target>

And if you don't want a particular option in the command then put a
comment, a single #, where the variable has been assigned.

A variation of this, to keep the assignments clean, may be to not
specify the option name in the assignment but conditionally expand
it where it's called; as in:

X=1
# Y=42
Z=99
your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"

If that's confusing to you, that would be with your option names:

MAX_RETRIES=1

nmap -T4 \
... \
${MAX_RETRIES:+ --max-retries ${MAX_RETRIES}} \
... \
<target>

And, as above, just comment out the assignment line(s).

Janis

>
> Regards
>

Hongyi Zhao

unread,
Mar 19, 2015, 11:43:59 PM3/19/15
to
On Fri, 20 Mar 2015 04:00:14 +0100, Janis Papanagnou wrote:

> MAX_RETRIES=1
>
> nmap -T4 \
> ... \
> ${MAX_RETRIES:+ --max-retries ${MAX_RETRIES}} \
> ... \
> <target>
>
> And, as above, just comment out the assignment line(s).

Thanks a lot for your clean solutions.

Regards
>
> Janis

Thomas 'PointedEars' Lahn

unread,
Mar 21, 2015, 8:40:40 AM3/21/15
to
Janis Papanagnou wrote:

> X=1
> # Y=42
> Z=99
> your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"

Most certainly it does not work with these quotes, because after expansion
the positional arguments would be “xoptname $X” where $X would be expanded
aso. And it would still be error-prone because $X, $Y and $Z could contain
a character in $IFS, inadvertently creating another positional argument.
Should be

your_cmd ${X:+xoptname "$X"} ${Y:+yoptname "$Y"} ${Z:+zoptname "$Z"}

The timid might even want to quote the option name.

--
PointedEars

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

Janis Papanagnou

unread,
Mar 21, 2015, 9:03:24 AM3/21/15
to
Am 21.03.2015 um 13:38 schrieb Thomas 'PointedEars' Lahn:
> Janis Papanagnou wrote:
>
>> X=1
>> # Y=42
>> Z=99
>> your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"
>
> Most certainly it does not work with these quotes, [...]

Yes, you are right. (I typed without thinking.) The application samples
that I gave did (for that reason) not have the quotes. Thanks.

Janis

Rakesh Sharma

unread,
Mar 21, 2015, 11:26:06 AM3/21/15
to
On Saturday, March 21, 2015 at 6:10:40 PM UTC+5:30, Thomas 'PointedEars' Lahn wrote:
> > X=1
> > # Y=42
> > Z=99
> > your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"
>
> Most certainly it does not work with these quotes, because after expansion
> the positional arguments would be "xoptname $X" where $X would be expanded
> aso. And it would still be error-prone because $X, $Y and $Z could contain
> a character in $IFS, inadvertently creating another positional argument.
> Should be
>
> your_cmd ${X:+xoptname "$X"} ${Y:+yoptname "$Y"} ${Z:+zoptname "$Z"}
>
> The timid might even want to quote the option name.
>
> --
> PointedEars


There would be no word splitting happening in the case of since it happens
only once when the your_cmd command line is parsed.
> > your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"

as the arguments are quoted, so even if it were to contain any IFS characters,
it wouldn't lead to any further positional arguments.
The arguments to your_cmd would be exactly 3.

It's another matter that it is wrong, since the +xoptname would be clubbed with $X !

-- Rakesh


Thomas 'PointedEars' Lahn

unread,
Mar 21, 2015, 12:17:36 PM3/21/15
to
Rakesh Sharma wrote:

> […] Thomas 'PointedEars' Lahn wrote:
>> > X=1
>> > # Y=42
>> > Z=99
>> > your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"
>>
>> Most certainly it does not work with these quotes, because after
>> expansion the positional arguments would be "xoptname $X" where $X would
>> be expanded aso. And it would still be error-prone because $X, $Y and $Z
>> could contain a character in $IFS, inadvertently creating another
>> positional argument. Should be
>>
>> your_cmd ${X:+xoptname "$X"} ${Y:+yoptname "$Y"} ${Z:+zoptname "$Z"}
>>
>> The timid might even want to quote the option name.
>
> There would be no word splitting happening in the case of since it happens
> only once when the your_cmd command line is parsed.
>
>> > your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"
>
> as the arguments are quoted, so even if it were to contain any IFS
> characters, it wouldn't lead to any further positional arguments.
> The arguments to your_cmd would be exactly 3.

ACK, thx. I should have been more clear: Not only have the double-quotes to
be omitted outside, they have to be inserted inside (“it *still* would be
error-prone”).

$ sh -xc 'X="1 2"; Y="3 4"; Z="5 6"; foo () { echo $#; }; foo ${X:+xoptname
$X} ${Y:+yoptname $Y} ${Z:+zoptname $Z}'
+ X=1 2
+ Y=3 4
+ Z=5 6
+ foo xoptname 1 2 yoptname 3 4 zoptname 5 6
+ echo 9
9

$ sh -xc 'X="1 2"; Y="3 4"; Z="5 6"; foo () { echo $#; }; foo ${X:+xoptname
"$X"} ${Y:+yoptname "$Y"} ${Z:+zoptname "$Z"}'
+ X=1 2
+ Y=3 4
+ Z=5 6
+ foo xoptname 1 2 yoptname 3 4 zoptname 5 6
+ echo 6
6

Also, user-defined variables should be lowercase so that they do not
conflict with environment variables: X, Y, and Z should be x, y, and z,
respectively.

Janis Papanagnou

unread,
Mar 21, 2015, 12:28:07 PM3/21/15
to
Am 21.03.2015 um 17:15 schrieb Thomas 'PointedEars' Lahn:
> Rakesh Sharma wrote:
>
[...]
>>
>> There would be no word splitting happening in the case of since it happens
>> only once when the your_cmd command line is parsed.
>>
>>>> your_cmd "${X:+xoptname $X}" "${Y:+yoptname $Y}" "${Z:+zoptname $Z}"
>>
>> as the arguments are quoted, so even if it were to contain any IFS
>> characters, it wouldn't lead to any further positional arguments.
>> The arguments to your_cmd would be exactly 3.
>
> ACK, thx. I should have been more clear: Not only have the double-quotes to
> be omitted outside, they have to be inserted inside (“it *still* would be
> error-prone”).

This is important to be aware of as a general caveat. In the given
case (see the OP's sample) we don't have data like you subsequently
showed, we have single values.

Janis

>
> $ sh -xc 'X="1 2"; Y="3 4"; Z="5 6"; foo () { echo $#; }; foo ${X:+xoptname
> $X} ${Y:+yoptname $Y} ${Z:+zoptname $Z}'
> [...]

Rakesh Sharma

unread,
Mar 21, 2015, 12:39:13 PM3/21/15
to
On Saturday, March 21, 2015 at 9:47:36 PM UTC+5:30, Thomas 'PointedEars' Lahn wrote:
> Rakesh Sharma wrote:
You are right in that the $X needs quoting. But there's one more slight
wrinkle here in case $X happens to be null but defined. In such a scenario
the construct ${varname:+...."${varname}"} => would not supply this argument
to the you_cmd function/script. Assuming that function does care for null args.

The most secure way is the following:
${varname+--argname "$varname"}

Note: This is exactly the same as the famous dictum ${1+"$@"}

--Rakesh
0 new messages