Why Are the Backslash and Semicolon Required With the Find Command'S -Exec Option

How do I make a list in CMake with the semicolon value?

You are on the right track by escaping the semicolon with a backslash. However, when setting the list in the ENVIRONMENT test property, this is not the last place the list will be used (and interpreted by CMake). The MY_TEST_ENVIRONMENT list is then used to populate CTestTestfile.cmake, which is later read by CTest to setup your test environment.

In short, you need more escape characters to propagate the semicolons through to the test environment. Specifically, use a double backslash \\ to escape an extra backslash into the list, along with the \; escaped semicolon. Here is CMake's escape characters documentation for reference. In total, three backslashes should work:

list(
  APPEND
  MY_TEST_ENVIRONMENT
  "MY_FLAG=1"
)

# <...>

list(
  APPEND
  MY_TEST_ENVIRONMENT
  "PATH=first_folder_path\\\;second_folder_path"
#                         ^--- Use three backslashes here
)

# <...>

set_property(TEST MyTests PROPERTY ENVIRONMENT ${MY_TEST_ENVIRONMENT})

Assigning a value having semicolon (';') to a variable in bash

I find it interesting that the use of back-ticks gives one result (your result) and the use of $(...) gives another result (the wanted result):

$ echo "hello;" | sed 's/\([^\\]\);/\1\\;/g'
hello\;
$ z1=$(echo "hello;" | sed 's/\([^\\]\);/\1\\;/g')
$ z2=`echo "hello;" | sed 's/\([^\\]\);/\1\\;/g'`
$ printf "%s\n" "$z1" "$z2"
hello\;
hello;
$

If ever you needed an argument for using the modern x=$(...) notation in preference to the older x=`...` notation, this is probably it. The shell does an extra round of backslash interpretation with the back-ticks. I can demonstrate this with a little program I use when debugging shell scripts called al (for 'argument list'); you can simulate it with printf "%s\n":

$ z2=`echo "hello;" | al sed 's/\([^\\]\);/\1\\;/g'`
$ echo "$z2"
sed
s/\([^\]\);/\1\;/g
$ z1=$(echo "hello;" | al sed 's/\([^\\]\);/\1\\;/g')
$ echo "$z1"
sed
s/\([^\\]\);/\1\\;/g
$ z1=$(echo "hello;" | printf "%s\n" sed 's/\([^\\]\);/\1\\;/g')
$ echo "$z1"
sed
s/\([^\\]\);/\1\\;/g
$ 

As you can see, the script executed by sed differs depending on whether you use x=$(...) notation or x=`...` notation.

s/\([^\]\);/\1\;/g            # ``
s/\([^\\]\);/\1\\;/g          # $()

Summary

Use $(...); it is easier to understand.

How to escape semicolon in C system function

system invokes the shell. On Unix that's most commonly either a derivative of sh or a derivative of csh. POSIX specifies only sh (thanks @KeithThompson). Both families of shells treat unescaped ; as a command separator.

To escape a character according to shell rules, one would precede it with a backslash, or enclose it in quotes. C has its own rules regarding quotes and backslashes in strings, so more backslashes are usually needed. Single quotes have a nice property of needing no backslashes in C strings.

So any of these should work:

"..... ';' ....."

"..... \";\" ....."

"..... \\; ....."

Semi-colon in Makefile rule definition

A semicolon on the line with the target-prerequisite is the first command line to execute for this rule, at least in GNU make.

From chapter 5 of the manual:

The commands of a rule consist of shell command lines to be executed
one by one. Each command line must start with a tab, except that the
first command line may be attached to the target-and-prerequisites
line with a semicolon in between.

In your case since there is no command after the semi-colon then it ends up being a no-op.

Colon (:) appears as forward slash (/) when creating file name

Once upon a time, before Mac OS X, : was the directory separator instead of /. Apparently OS X 10.7 is still trying to fix up programs like that. I don't know how you can fix this, if you really need the : to be there. I'd omit it :-).

EDIT: After a bit more searching this USENIX paper describes what is going on. The rule they use apparently is this:

Another obvious problem is the different path separators between HFS+ (colon, ':') and UFS
(slash, '/'). This also means that HFS+ file names may contain the slash character and not
colons, while the opposite is true for UFS file names. This was easy to address, though it
involves transforming strings back and forth. The HFS+ implementation in the kernel's VFS
layer converts colon to slash and vice versa when reading from and writing to the on-disk
format. So on disk the separator is a colon, but at the VFS layer (and therefore anything
above it and the kernel, such as libc) it's a slash. However, the traditional Mac OS
toolkits expect colons, so above the BSD layer, the core Carbon toolkit does yet another
translation. The result is that Carbon applications see colons, and everyone else sees
slashes. This can create a user-visible schizophrenia in the rare cases of file names
containing colon characters, which appear to Carbon applications as slash characters, but
to BSD programs and Cocoa applications as colons.

---

Related Topics