Hilarious Unix Commands

Ovid on 2006-11-30T14:27:45

I was terribly amused, when doing some research on one of our servers, to see the following line in the command history:

ln -s /usr/bin/perl /usr/bin/perl\r

Of course, that didn't work, and apparently successive attempts failed until eventually, the following was used:

perl -e'symlink($_ => "$_\r") for @ARGV' /usr/bin/perl /usr/bin/python /usr/bin/ruby

This was done because these are dedicated servers and customers sometime FTP programs written on a Windows box to their Linux box and the symlink was considered easier than writing a custom FTP server or running a cron job to find the errant files :)

Can anyone think of a better solution which doesn't require manual intervention after setting up a dedicated server for a customer who doesn't know about line endings?


Log surfing

jjore on 2006-11-30T16:39:06

You could follow the log and dos2unix any text files in the "scripts" area.

shell quoting of special chars

uri on 2006-11-30T17:58:24

i had no trouble getting this to work in shell. you need to type ^V to quote a real return (^M) and it works fine:

ln -s foo foo^M
lrwxrwxrwx 1 uri staff 3 Nov 30 12:53 foo? -> foo

but your perl solution is fine too.

uri

some of ftp daemon support upload filter

ccpp0 on 2006-12-01T06:21:06

e.g. pure-ftpd, with pure-uploadscript support, you can write a simple shell script to convert files from crlf to lf

No -s

Abigail on 2006-12-01T11:38:53

I'd consider using a hard link 'better' than using a symlink - it requires less file system access to get to the binary. It also uses marginally less disk space - and less inodes.

But I don't think you were looking for this kind of 'better'.

Re:No -s

drhyde on 2006-12-01T22:47:53

A common bug in backup software is that it often doesn't handle multiple links properly - perl and perl\r would both get backed up as seperate files, and restored with different inodes. When you later upgrade perl, the confusing "wrong" (ie, old) behaviour of perl\r can be very hard to debug.