Bash – UTF-8 and !# shell scripts

The answer is simple — it's a relic of times where terminals were 80 characters wide. Look at your own example — username & host occupies already 16 chars. With additional brackets and spaces there's 20 chars already, and we haven't counted the directory name yet.

And the directories can have pretty long names, too. Your example path counts 21 chars and it's only three directories deep. In such case, on 80-char terminal that prompt will occupy half of the screen width.

Of course, today terminals are wider and that's why many users & distros switch to longer prompts. But there's still some which use a narrower prompt to leave the user more space to type.

I have to deal with this on occasion with some legacy systems. Sometimes the files retained in the organization's source control (Borland Starteam) were set to the wrong linefeed configuration.

But working in a number of cross-platform environments, copy/paste should not cause this issue alone. Try to identify the trends based on the output from the following and deal with the worst offenders appropriately.

Periodically search for files with DOS linefeeds.

find /var/www -not -type d -exec file "{}" ";" | grep CRLF

Example:

# find /ppro/bin -not -type d -exec file "{}" ";" | grep CRLF
/ppro/bin/compile/save/srcfix.c: ASCII C program text, with CRLF line terminators
/ppro/bin/compile/bldtag.c: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/compile/bldtag.c.sav: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/compile/dbcsum2.c: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/hphw/print_sv.c: ASCII text, with CRLF line terminators
/ppro/bin/linuxhw/dhcpd.conf: ASCII text, with CRLF line terminators
/ppro/bin/linuxhw/dhcpd.conf.mult_subnet: ASCII text, with CRLF line terminators

Then BURN them!!

Remember, that dos2unix on some systems will modify permissions...