appending text to EOF

[christiniaroelin]

Guru's
Im trying to append a text to the end of a file:

INPUT FILE :
i am
learing
sed.

TEST TO APPEND:
today

DESIRED OUTPUT FILE:
i am
learing
sed.
today

please provide with any insights.

Thanks Much.

 

[TrojanWarBlade]

To append text you just need to redirect the output using ">>"
E.G.

echo "today" >> file_to_append_to.txt

Trojan.

 

[feherke]

Hi

Is a nonsense, but while you asked for [tt]sed[/tt]...

sed -i '$atoday' file_to_append_to.txt

Feherke.

http://rootshell.be/~feherke/

 

[stefanwagner]

@christiniaroelin:
Perhaps you expect that there is a special binary character, meaning 'EOF', but if you generate a file, just containing 'abc' you will see it is 3 bytes long.

There is no EOF-character.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[KenCunningham]

Not wishing to split hairs, Stefan, but if you create a file containing 'abc', it's actually 4 bytes when listed with ls -la ;-)

 

[feherke]

Hi

Could be filesystem dependent ?

[blue]master #[/blue] echo -n 'abc' > sizequestion

[blue]master #[/blue] ls -la sizequestion
-rw-r--r--    1 master  users           3 2005-10-10 10:57 sizequestion

[blue]master #[/blue] df -T
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/hda2 reiserfs    12851600  12838888     12712 100% /

Feherke.

http://rootshell.be/~feherke/

 

[hoinz]

Also not wishing to split hairs, Ken, but I think it depends.
If you use common Unix commands like vi or echo, then yes, you are right, there will be an additional byte.
On the other other hand, you may write a little C programm that will create a file containg'abc', and nothing else.


... and just before pressing 'submit', I saw feherke's post.
Very interesting.
On Tru64 Unix, advfs, I get 4 bytes.

 

[KenCunningham]

Interesting indeed. It would be interesting to know what flavour of echo supports this -n option - gnu perhaps?

 

[hoinz]

... or could it be a Unix/Linux issue?
I just did two other tests.
No extra byte in SuSE Linux, ext3 filesystem,
an extra byte in HP-UX 11i, vxfs.

regards

 

[hoinz]

yes, it must be that -n option.
In SuSE Linux, there is an extra byte, when I omit -n.
And in HP-UX, Tru64 there isn't a -n anyways.

 

[feherke]

Hi

It would be interesting to know what flavour of echo supports this -n option - gnu perhaps?

[blue]master #[/blue] type echo
echo is a shell builtin

[blue]master #[/blue] echo $SHELL
/bin/bash

[blue]master #[/blue] bash --version
GNU bash, version 2.05b.0(1)-release (i586-suse-linux)
Copyright (C) 2002 Free Software Foundation, Inc.

[blue]master #[/blue] man bash | col -b | grep -m1 -A3 echo
       echo [-neE] [arg ...]
              Output the args, separated by spaces, followed by a
              newline.  The return status is always 0.  If -n  is
              specified,  the trailing newline is suppressed.  If

Feherke.

http://rootshell.be/~feherke/

 

[KenCunningham]

Thanks, Feherke.

 

[TrojanWarBlade]

If you look at the data in the file:

od -c sizequestion

you will see that "vi" and others automatically add a linefeed whereas "echo" does not. That is the reason for the extra byte. It is still NOT and eof character.


Trojan.

 

[stefanwagner]

Not wishing to split hairs, Stefan, but if you create a file containing 'abc', it's actually 4 bytes when listed with ls -la

I like splitting hairs, and if 'ls -la abc' says the file is 4 bytes long, it's definitely not only containing 'abc' but something else.

Whether vi, echo or something else is adding something - I would remove it.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[p5wizard]

echo "abc" outputs the string "abc\n" (including newline)
echo -n "abc" outputs the string "abc" on some UNIX flavours (suppresses the newline)
echo "abc\c" works the same on other flavours - also suppresses the newline
printf "abc" outputs the string "abc"
printf "abc\n" outputs the strings "abc\n"

note that some shells have a builtin echo command which may behave differently from /bin/echo.

with vi or ed, the newline is automatically added to every typed line - it is impossible to suppress it.

for more info:see

http://www.in-ulm.de/~mascheck/various/echo/

HTH,

p5wizard

 

[SamBones]

Whether vi, echo or something else is adding something - I would remove it.

That something else is a linefeed character (0x0A). It's not bad to have so you don't need to remove it.

And unix does have an EOF character. It's Ctrl-D. This can even be used to log out, because you are telling your shell that there's nothing more at [tt]stdin[/tt] to read. It's reached the end of file for [tt]stdin[/tt]. You can also use Ctrl-D to terminate a [tt]cat[/tt] from [tt]stdin[/tt] because it's the end-of-file character.

$ cat > file.out
type in some text
this goes into the file
^D
$

But, this Ctrl-D is usually not stored in the file (unless some program has written it in).

Hope this helps.

 

[stefanwagner]

That something else is a linefeed character (0x0A). It's not bad to have so you don't need to remove it.

Well - it depends.
It might lead to an empty page being printed.

But, this Ctrl-D is usually not stored in the file (unless some program has written it in).

Well - and if it is written into the file, the file might continue after it?
Nice idea!

Having an EOF-character would be very funny for binary files, would waste 1/255 of the characterspace for one position in files, and prevent saving small numbers efficiently.

If I remember correctly, we might read unsigned characters in c from a file (scope: 0-255) and the function isn't returning unsigned char, but int, and -1 which is out of the unsigned char - scope, is returned to indicate EOF.

Ctrl-D is an interrupt, afaik, not a character.

Of course you're free to interpret a choosen character as EOF in your own fileformats, and I know, some people did.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung