Trouble constructing a UNIX statement command line

[Keith G.]

I am having trouble constructing a "sed" command for execution from a UNIX statement. What I want to send to the shell is this:

sed -i'.bak' 's/\o14//g' [Filename_here]

But no matter what I've tried, I cannot yet get the single quotes to pass through, as far as I can tell.

I am likely overlooking something obvious to those with more experience with this sort of thing. Any tips?

 

[TomBascom]

My first tip is that if you are going to ask questions about code, you really ought to post the code in question. We are very bad mind-readers.

My second tip is that if you are posting code, please use [ c o d e ] tags so that we can actually read it with reasonable formatting (see blow).

Let us suppose, just for giggles, that your code looks something like this.

os-command sed -i'.bak' 's/\o14//g' filename.

I'm guessing that you might be debugging that with something like:

os-command sed -i'.bak' 's/\o14//g' filename ; sleep 60.

Which results in:

[tom @ protopdev ~] $ ps -ef | grep sleep
tom      28699 25217  0 14:43 pts/6    00:00:00 /bin/bash -c sed -i'.bak' s/o14//g filename ; sleep 60
tom      28701 28699  0 14:43 pts/6    00:00:00 sleep 60

Note that the "\" character has disappeared. That is because it is an "escape" character in 4gl strings. You need to code that as "~\" resulting in a test command like this:

os-command sed -i'.bak' 's/~\o14//g' filename ; sleep 60.

Which gives better output:

[tom @ protopdev ~] $ ps -ef | grep sleep
tom      30064 25217  0 14:49 pts/6    00:00:00 /bin/bash -c sed -i'.bak' s/\o14//g filename ; sleep 60
tom      30066 30064  0 14:49 pts/6    00:00:00 sleep 60

Looking at that I am kind of wondering if you are trying to search for an ocatl 014, aka form-feed, rather than \o14 (whatever that is)

Still missing your second set of single quotes although I also can't see what you would need them for.

None the less, keeping after the goal, the 4gl supports the use of either single or double quotes to build strings. Which is really handy when you want to embed one type of quote into a string. So:

os-command "sed -i'.bak' 's/~\o14//g' filename ; sleep 60".

Finally, this looks like what you are aiming for:

$ ps -ef | grep sed
tom        348 25217  0 15:00 pts/6    00:00:00 /bin/bash -c sed -i'.bak' 's/\o14//g' filename ; sleep 60
tom        352 27473  0 15:00 pts/7    00:00:00 grep --color=auto sed

 

[Rob Fitzpatrick]

It seems to work when I enclose the command in double quotes, e.g. unix "sed -i'.bak' 's/\o14//g' foo".

 

[Keith G.]

Yes, I am trying to strip form feed characters from the victim file. I see now that I can use "\f" rather than the octal "\o14", making the code a little more readable.

Here's some code I am running to test this:

define var svFilename as char no-undo init "/u/tmp/reports/KGER10:08:31dat".
define var svCmd as char no-undo.
svCmd = "sed -i'.bak' 's/~\f//g' ".
os-command value (substitute ("echo &1 &2", svCmd, svFilename)).

The output:

sed -i.bak s/\f//g /u/tmp/reports/KGER10:08:31dat

No single quotes at all appear in that output.

 

[TomBascom]

How do you know that no single quotes appear in the command? Because of the echoed output to the screen? That's showing you the output of "echo" not the command line itself. Try adding the "sleep 60" trick and looking at the command line with "ps -ef | grep sleep"

 

[TomBascom]

To be clear - the point about adding "; sleep 60" to your command is that it gives you 60 seconds to run a "ps -ef | grep sleep" in another window so that you can observe the actual command line that is being passed to the shell.

Any time that you have quoting and variable substitution etc the echoed output returned to the session is not likely to be the same as the original command line.

 

[Keith G.]

Well, that was an assumption on my part, an invalid one as it turns out. The single quotes do indeed show up in the command line when examined via the "ps" command.

And with that, my goal has been met--the stripping of form feeds from that output file finally works. Case closed!

Thanks for all the help. This forum is such a great resource.