UNIX for Beginners Questions & Answers

GNU sed has the [ICODE]-c/--copy[/ICODE] Option which keeps hard+soft links. But this is not an atomic operation. (the mv-Variant is atomic).

Alternatively sponge is there too. (Not very portable, too ;-) ).

Sponge soaks up stdin and after that writes to stdout:

Code:

sed -e s/bla/blub/ file.txt | sponge file.txt

One should know when atomic updates are more important than keeping files/inodes and vice versa. Use the solution which fits your case.

Note
GNU sed version 4.7.6(current sed git version) does not contain --copy. There is a man-page on the web(This one: sed(1) - Linux man page) which states there is a --copy. But it seems not to be really there.

another option

Code:

sed 'y%-%/%' file

Hello Bakunin sir,

With full respect I competely agree with you on this part, would like to add 1 point here that GNU sed is having -i.bak option too, which takes backup of Input_file before editing it in-place, here is an example for same.

Let's say following is my Input_file:

Code:

cat Input_file
A                           B        C                  D

Now when I run following command:

Code:

sed -i.bak 's/^A/Singh/'   Input_file

I could see backup file named Input_file.bak is created with actual content and Input_file is in-placed with new string. IMHO may be we could use this for safer side?

Code:

-rw-r--r--  1 singh  test_singh_bla   411 Mar 15 09:00 Input_file.bak
-rw-r--r--  1 singh  test_singh_bla   415 Mar 15 09:01 Input_file

Thanks,
R. Singh

First: I haven't known that, so thank you for teaching me something new.

The point was not that it takes or takes not a backup, that it changes or doesn't change the inode (as MadeInGermany mentioned - thank you for providing a way to circumvent that too, should the need arise), though. It should be worth noting, though, that using a mv within filesystem boundaries is faster than cp. Across filesystems mv and cp are probably equally fast.

For me the main point is portability. I can choose between using the POSIX-way of doing things and that works on all systems and using the GNU-way and that works on less than all systems. For the same reason i would rather hesitate to use a feature in the POSIX-standard which i know would not work (or work differently) on GNU. This is not limited to sed options or something particular at all. The same goes for anything else i do on a UNIX (or Linux) system.

The second reason i would not suggest to use -i is NOT, that it rolls some usually necessary actions into one: i talked about not preserving the inode or filemode or owner, but it won't always matter if they are being preserved or not. The point is it makes it look like it would be the same file while it is not. One can do everything and anything but one: lie to your users. If you do something, whatever it is, do it - but don't pretend you do something else.

bakunin

You're right. The exact method is not fully explained in the man-page. There's only a very short sentence about -i.

In the sed info-page however it is explained more in detail.

Code:

'-i[SUFFIX]'
'--in-place[=SUFFIX]'
     This option specifies that files are to be edited in-place.  GNU
     'sed' does this by creating a temporary file and sending output to
      this file rather than to the standard output.(1).

I would feel better if somone's called a liar not so easily.

---

What's regarding portability, I think the message is clear:
If one wants portability: Stick to POSIX. Don't use GNU, bash, php, python, ruby, whatever, ...

Speaking strictly as a scientist: python ruby, and julia are extremely important for research and analysis.

GNU supports the environment variable POSIXLY_CORRECT. This helps a lot when you are porting code back and forth between several platforms. I would suggest that you check it out. Defining it changes behavior to be pretty close to POSIX. Not perfect, IMO.

Linux is effectively inescapable in modern data centers. Even appliances like routers run on embedded Linux. So does your refrigerator ....

GNU.org position on POSIX:
GNU Coding Standards: Non-GNU Standards

Some OSes kind of go off the deep end in attempt to be a sort of "all versions of standards" - which is kind of what you are discussing here.

Solaris is an example:

Compliance with standards in that OS - for a new user or somebody porting an app - can be confusing. You get different versions of awk, tr and so on. This depends on which of several possible paths, and their order, ex: /usr/xpg4/bin versus /usr/bin, you have set up in PATH. This can break a lot of things that worked correctly on HP-UX but not Solaris, for example. I spent a lot of time tweaking the PATH variable for different applications and their associated users

XPG4 -
man pages section 5: Standards, Environments, and Macros

Don Cragun here actively works on standards, and definitely will have have some opinions here.

Maybe the Standards-Part should be separated from the thread? (Last time I requested Thread separation there was a broken thread afterwards in the forum, which might have nothing to do with that, but I just wanted to mention).

--- Post updated at 03:08 PM ---

I would throw in another question:

Does POSIX contain a programming language environment?
Is there a programming language available in every environment?

In contrast to Linux the situation of HP-UX,Solaris,AIX, ... in terms of easy available and easy installable software for me(as linux-only-user) seems like the availablity of water in the ocean and the desert.

So I'm wondering if there is any programming language installed in those unices so there maybe one programming environment available everywhere. I'm not talking about sh/ksh/bash. I do not consider them as real programming language. Yes, one can write very large shell scripts, but I think it's a mess. Bad maintainability. Slow Speed. High Resource Footprint(New process creatings for most things). Unsafe Programming environment. Inferior programming feature set.

I would imagine perl 5(perl 5 is 25 years old now. Having perl means: just the perl-base, no modules) could be everywhere. Despite being the opposite of my favourite programming language, if I had/wanted to write portable code, perl would be a lot better than any shell. The developer of inxi(hardware information tool,Inxi at github) went that way - inxi a 20,000 line perl script - written targeted at very high compatibility(Before switching to perl he had used bash and gnu awk).