Escaped to multi-line format - Revision history

Jimbo: Reverted edits by 83.211.3.16 (Talk); changed back to last version by Jimbo

2007-05-05T18:14:39Z

Reverted edits by 83.211.3.16 (Talk); changed back to last version by Jimbo

Jimbo at 09:22, 22 February 2005

2005-02-22T09:22:42Z

169.229.74.115 at 07:36, 22 February 2005

2005-02-22T07:36:12Z

Dave at 05:00, 29 January 2005

2005-01-29T05:00:25Z

Jimbo: added link to "escaping"

2005-01-28T14:42:45Z

added link to "escaping"

Jimbo at 21:37, 14 December 2004

2004-12-14T21:37:17Z

Jimbo at 21:36, 14 December 2004

2004-12-14T21:36:55Z

Jimbo at 21:35, 14 December 2004

2004-12-14T21:35:13Z

New page

An often-followed convention when reproducing shell scripts online is "escaping" very long lines, using the backslash character, into multiple lines for readability. For example, the following simple script, which concatenates a lot of files into one file named "all.files":

#!/bin/sh
cat one.file two.file three.file four.file five.file six.file seven.file eight.file > all.files

Could be rendered like this:

#!/bin/sh
cat one.file two.file three.file \
four.file five.file six.file \
seven.file eight.file \
> all.files

On most machines, the script should work exactly the same in escaped format as it does in the normal, unescaped format. However, I tend to recommend removing the backslashes and carriage returns and entering lines expressed this way as single continous lines, when actually entering in scripts - because while anything ''should'' work fine escaped, I have very occasionally seen source code that refused to work in escaped format but did work once the escapes were removed and the lines concatenated. So if you don't escape to multiple lines, you have one less thing to worry about potentially having to fix.

[[Category:FreeBSD Terminology]]

← Older revision		Revision as of 09:22, 22 February 2005
Line 14:		Line 14:
	> all.files		> all.files

		+	Be aware that in some rare cases (in particular, I have seen this occur in Makefiles) there may be problems associated with escaping long lines - so if you're having strange inexplicable issues with a script not working right that has multi-line escapes in it, you might want to try returning any multi-lines to standard format to see if that fixes the problem.
	[[Category:FreeBSD Terminology]]		[[Category:FreeBSD Terminology]]

@@ Line 14: / Line 14: @@
   > all.files
-On most machines, the script should work exactly the same in escaped format as it does in the normal, unescaped format.  However, I tend to recommend removing the backslashes and carriage returns and entering lines expressed this way as single continous lines - because while anything ''should'' work fine escaped, I have very occasionally seen source code that refused to work in escaped format but did work once the escapes were removed and the lines concatenated.  So if you don't escape to multiple lines, you have one less thing to worry about potentially having to fix.
+On most machines, the script should work exactly the same in escaped format as it does in the normal, unescaped format.  However, I tend to recommend removing the backslashes and carriage returns and entering lines expressed this way as single continous lines - because while anything ''should'' work fine escaped, I have very occasionally seen source code that refused to work in escaped format but did work once the escapes were removed and the lines concatenated.  So if you don't escape to multiple lines, you have one less thing to worry about potentially having to fix. This is often because of the way that a particular [[shell]] treats the \ character; the Bourne shell [[sh]] is ubiquitous and should not have these issues but you should avoid the \ use Just In Case.
 [[Category:FreeBSD Terminology]]

← Older revision		Revision as of 14:42, 28 January 2005
Line 1:		Line 1:
−	An often-followed convention when reproducing shell scripts online is "escaping" carriage returns, using the backslash character, in order to render single very long continous lines into multiple lines for readability. For example, the following simple script, which concatenates a lot of files into one file named "all.files":	+	An often-followed convention when reproducing shell scripts online is [[escaping]] carriage returns, using the backslash character, in order to render single very long continous lines into multiple lines for readability. For example, the following simple script, which concatenates a lot of files into one file named "all.files":

	#!/bin/sh		#!/bin/sh

@@ Line 2: / Line 2: @@
   #!/bin/sh
   cat one.file two.file three.file four.file five.file six.file seven.file eight.file > all.files
@@ Line 7: / Line 8: @@
   #!/bin/sh
   cat one.file two.file three.file \
   four.file five.file six.file \

@@ Line 1: / Line 1: @@
-An often-followed convention when reproducing shell scripts online is "escaping" very long lines, using the backslash character, into multiple lines for readability.  For example, the following simple script, which concatenates a lot of files into one file named "all.files":
+An often-followed convention when reproducing shell scripts online is "escaping" carriage returns, using the backslash character, in order to render single very long continous lines into multiple lines for readability.  For example, the following simple script, which concatenates a lot of files into one file named "all.files":
   #!/bin/sh
@@ Line 12: / Line 12: @@
   > all.files
-On most machines, the script should work exactly the same in escaped format as it does in the normal, unescaped format.  However, I tend to recommend removing the backslashes and carriage returns and entering lines expressed this way as single continous lines, when actually entering in scripts - because while anything ''should'' work fine escaped, I have very occasionally seen source code that refused to work in escaped format but did work once the escapes were removed and the lines concatenated.  So if you don't escape to multiple lines, you have one less thing to worry about potentially having to fix.
+On most machines, the script should work exactly the same in escaped format as it does in the normal, unescaped format.  However, I tend to recommend removing the backslashes and carriage returns and entering lines expressed this way as single continous lines - because while anything ''should'' work fine escaped, I have very occasionally seen source code that refused to work in escaped format but did work once the escapes were removed and the lines concatenated.  So if you don't escape to multiple lines, you have one less thing to worry about potentially having to fix.
 [[Category:FreeBSD Terminology]]