Comments between parameters in BASH

Question

I want to include command parameters - inline comments, for example:

sed -i.bak -r \ # comment 1 -e 'sed_commands' \ # comment 2 -e 'sed_commands' \ # comment 3 -e 'sed_commands' \ /path/to/file 

The code above does not work. Is there any other way to nest comments in a parameter string?

Answer 1

If you really need comment arguments, you can try the following:

 ls $( echo '-l' #for the long list echo '-F' #show file types too echo '-t' #sort by time ) 

This will be equivalent to:

 ls -l -F -t 

echo is a built-in shell, therefore it does not execute external commands, so it is fast enough. But in any case, this is crazy.

or

 makeargs() { while read line; do echo ${line//#*/}; done } ls $(makeargs <<EOF -l # CDEWDWEls -F #Dwfwef EOF ) 

Answer 2

I would recommend using longer text blocks for your sed script, i.e.

 sed -i.bak ' # comment 1 sed_commands # comment 2 sed_commands # comment 3 sed_commands ' /path/to/file 

Unfortunately, inline comments in sed script blocks are not a universally supported function. The sun4 version will allow you to put a comment on the first line, but not somewhere else. AIX sed either does not allow comments, or uses char instead of # for comments. Your results may vary.

Hope this helps.

Answer 3

You can call sed several times instead of passing all arguments to one process:

 sed sed_commands | # comment 1 sed sed_commands | # comment 2 sed sed_commands | # comment 3 sed sed_commands # final comment 

This is clearly more wasteful, but you can decide that the three additional sed processes are a fair compromise for readability and portability (to @shellter indicates support for comments in sed commands). Depends on your situation.

UPDATE: you will also have to adjust if you originally planned to edit the files in place, as your -i argument suggests. This approach will require a conveyor.

Answer 4

There is no way to do what you are trying to do in shell plus sed. I put comments before the sed script, for example:

 # This is a remarkably straight-forward SED script # -- When it encounters an end of here-document followed by # the start of the next here document, it deletes both lines. # This cuts down vastly on the number of processes which are run. # -- It also does a substitution for XXXX, because the script which # put the XXXX in place was quite hard enough without having to # worry about whether things were escaped enough times or not. cat >$tmp.3 <<EOF /^!\$/N /^!\\ncat <<'!'\$/d s%version XXXX%version $SOURCEDIR/% EOF # This is another entertaining SED script. # It takes the output from the shell script generated by running the # first script through the second script and into the shell, and # converts it back into an NMD file. # -- It initialises the hold space with --@ , which is a marker. # -- For lines which start with the marker, it adds the pattern space # to the hold space and exchanges the hold and pattern space. It # then replaces a version number followed by a newline, the marker # and a version number by the just the new version number, but # replaces a version number followed by a newline and just the # marker by just the version number. This replaces the old version # number with the new one (when there is a new version number). # The line is printed and deleted. # -- Note that this code allows for an optional single word after the # version number. At the moment, the only valid value is 'binary' which # indicates that the file should not be version stamped by mknmd. # -- On any line which does not start with the marker, the line is # copied into the hold space, and if the original hold space # started with the marker, the line is deleted. Otherwise, of # course, it is printed. cat >$tmp.2 <<'EOF' 1{ x s/^/ --@ / x } /^ --@ /{ H x s/\([ ]\)[0-9.][0-9.]*\ n--@ \([0-9.]\)/\1\2/ s/\([ ]\)[0-9.][0-9.]*\([ ][ ]*[^ ]*\)\ n--@ \([0-9.][0-9.]*\)/\1\3\2/ s/\([ ][0-9.][0-9.]*\)\ n--@ $/\1/ s/\([ ][0-9.][0-9.]*[ ][ ]*[^ ]*\)\ n--@ $/\1/ p d } /^ --@ /!{ x /^ --@ /d } EOF 

There is also a sed script in a file about 40 lines long (marked as "entertaining"), although approximately half of these lines are just a built-in shell script added to the output. I have not changed the shell of the script containing this material for 13 years, because (a) it works and (b) sed scripts scare me crazy. (The NMD format contains the file name and version number, separated by a space, and sometimes the word tag is “binary” instead of the version number, plus comment lines and blank lines.)

You don't need to understand what the script does, but commenting in front of the script is the best way I've found to document sed scripts.

Answer 5

Not.

If you put \ in front of # , it will remove the comment character and you will no longer have comments.

If you put \ after # , it will be part of the comment and you will no longer delete the new line.

The lack of inline comments is a bash limitation that you better adapt than try and work with some of the proposed baroque suggestions.

Answer 6

Although the stream is quite old, I found it on the same issue, and others will. Here is my solution for this problem:

You need comments, so if you look at your code much later, you will most likely get an idea of ​​what you actually did when you wrote the code. I have the same problem when I write my first rsync script, which has many parameters that also have side effects.

Group together your parameter, which belongs together by topic and puts them in a variable that gets the corresponding name. This makes it easy to determine what parameter controls. This is your short comment. Alternatively, you can put a comment on the variable declaration to see how you can change the behavior. This is a comment on the long version.

Call the application with the appropriate parameter variables.

 ## Options # Remove --whole-file for delta transfer sync_filesystem=" --one-file-system \ --recursive \ --relative \ --whole-file \ " ; rsync \ ${sync_filesystem} \ ${way_more_to_come} \ "${SOURCE}" \ "${DESTIN}" \ 

Good review, easy to edit and remind comments in options. This requires a lot of effort, but therefore has a higher quality.

Answer 7

I suggest another way that works, at least in some cases:

Say I have a command:

 foo --option1 --option2=blah --option3 option3val /tmp/bar` 

I can write like this:

 options=( --option1 --option2=blah --option3 option3val ) foo ${options[@]} /tmp/bar 

Now let me say that I want to temporarily remove the second option. I can just comment on this:

 options=( --option1 # --option2=blah --option3 option3val ) 

Note that this method may not work when you need extensive escaping or quotation mark. I ran into some problems with this in the past, but unfortunately I don't remember the details at the moment :(

In most cases, this method works well. If you need inline spaces in the parameter, just insert the string in quotation marks, as usual.