Shell – Add text with echo but start with new line if file not empty

echofilesshell-script

I'm trying to create next script

echo "#!/bin/sh" >/script
echo "del x.txt" >>/script

witch is ok if /script file is empty, if not – will append first line to last text

#!/bin/sh
del x.txt#!/bin/sh
del x.txt

If I add an echo empty line first it's ok again if file not empty, but if empty – the script will not be executed

echo "" >>/script
echo "#!/bin/sh" >>/script
echo "del x.txt" >>/script

EDIT:

I will explain exactly what I'm trying to do, on my asuswrt router I want to add a new rule to port forwarding script, witch is firewall-start

echo "#!/bin/sh" >/jffs/scripts/firewall-start
echo "" >>/jffs/scripts/firewall-start
echo "iptables -I INPUT -p tcp --destination-port 3000 -j ACCEPT" >>/jffs/scripts/firewall-start

This will overwrite any text in /jffs/scripts/firewall-start

I want a solution to create script from scratch or to append this lines but starting with new line and not to append text to the last line.
If I start with empty line and the script is empty, will not be executed after because #!/bin/sh should be in the first line

echo "" >>/jffs/scripts/firewall-start
echo "#!/bin/sh" >/jffs/scripts/firewall-start
echo "" >>/jffs/scripts/firewall-start
echo "iptables -I INPUT -p tcp --destination-port 3000 -j ACCEPT"

/jffs/scripts/firewall-start

Best Answer

You can test to see if a file is empty by using unix test -s. Example below...

 if [ -s $file ]
then
   echo "File size is zero"
else
   echo "File size is not zero"
fi

`echo`

An echo implementation which strictly conforms to the Single Unix Specification will add newlines if you do:

echo 'line1\nline2'

But that is not a reliable behavior. In fact, there really isn't any standard behavior which you can expect of echo.

OPERANDS

string

A string to be written to standard output. If the first operand is -n, or if any of the operands contain a <\backslash> character, the results are implementation-defined.

On XSI-conformant systems, if the first operand is -n, it shall be treated as a string, not an option. The following character sequences shall be recognized on XSI-conformant systems within any of the arguments:

\a - Write an <alert>.

\b - Write a <backspace>.

\c - Suppress the <newline> that otherwise follows the final argument in the output. All characters following the \c in the arguments shall be ignored.

\f - Write a <form-feed>.

\n - Write a <newline>.

\r - Write a <carriage-return>.

\t - Write a <tab>.

\v - Write a <vertical-tab>.

\\ - Write a <backslash> character.

\0num - Write an 8-bit value that is the zero, one, two, or three-digit octal number num.

And so there really isn't any general way to know how to write a newline with echo, except that you can generally rely on just doing echo to do so.

A bash shell typically does not conform to the specification, and handles the -n and other options, but even that is uncertain. You can do:

shopt -s xpg_echo
echo hey\\nthere

hey
there

And not even that is necessary if bash has been built with the build-time option...

--enable-xpg-echo-default

Make the echo builtin expand backslash-escaped characters by default, without requiring the -e option. This sets the default value of the xpg_echo shell option to on, which makes the Bash echo behave more like the version specified in the Single Unix Specification, version 3. See Bash Builtins, for a description of the escape sequences that echo recognizes.

`printf`

On the other hand, printf's behavior is pretty tame in comparison.

RATIONALE

The printf utility was added to provide functionality that has historically been provided by echo. However, due to irreconcilable differences in the various versions of echo extant, the version has few special features, leaving those to this new printf utility, which is based on one in the Ninth Edition system.

The EXTENDED DESCRIPTION section almost exactly matches the printf() function in the ISO C standard, although it is described in terms of the file format notation in XBD File Format Notation.

It handles format strings which describe its arguments - which can be any number of things, but for strings are pretty much either %byte strings or literal %strings. Other than the %formats in the first argument, it behaves most like a %byte string argument, except that it doesn't handle the \c escape.

printf ^%b%s$ '\n' '\n' '\t' '\t'

^
\n$^    \t$

See Why is printf better than echo? for more.

`echo() printf`

You might write your own standards conformant echo like...

echo(){
    printf '%b ' "$@\n\c"
}

...which should pretty much always do the right thing automatically.

Actually, no... That prints a literal \n at the tail of the arguments if the last argument ends in an odd number of <backslashes>.

But this doesn't:

echo()
    case    ${IFS- } in
    (\ *)   printf  %b\\n "$*";;
    (*)     IFS=\ $IFS
            printf  %b\\n "$*"
            IFS=${IFS#?}
    esac

Bash – Getting no output from command substitution

Here, if lsusb drops an error, the error message is not redirected, only errors from grep. Errors from lsusb still go the the usual stderr, i.e. the terminal (or whatever stderr was when the script started.

VENDOR=$(lsusb -D "$DEVICE" | grep idVendor 2>&1)

E.g.

$ blah=$(ls -l /nonexisting | grep foo 2>&1)
ls: cannot access '/nonexisting': No such file or directory
$ echo "blah: '$blah'"
blah: ''

You'll need to redirect both of their outputs as a group to have the command substitution capture the error, too:

$ blah=$( { ls -l /nonexisting | grep foo; } 2>&1)
$ echo "blah: '$blah'"
blah: 'ls: cannot access '/nonexisting': No such file or directory'

Using separate redirections like $( foo 2>&1 | grep 2>&1 ) would send the errors of the first command to the pipe, and for grep to filter, which in the above example would again produce an empty output.

Best Answer

Related Solutions

How to add new lines when using echo

echo

printf

echo() printf

Bash – Getting no output from command substitution

Related Question

`echo`

`printf`

`echo() printf`