Putting shell variables in single quotes disables their interpretation. That's why your command has no effect.
$ echo 's/"$OLD_STRING"/"$NEW_STRING"/g'
s/"$OLD_STRING"/"$NEW_STRING"/g
It should be written like that:
sed -i "s/'$OLD_STRING'/'$NEW_STRING'/g" jboss-beans.xml
But then the variables are interpreted before calling sed
and the again contain special characters:
$ echo "s/'$OLD_STRING'/'$NEW_STRING'/g"
s/'<property name="webServiceHost">${jboss.bind.address}</property>'/'<!--<property name="webServiceHost">${jboss.bind.address}</property>-->'/g
For that reason sed
has this special featur allowing to define the s///
command delimiters by simply using them, e.g.:
sed -i "s#'$OLD_STRING'#'$NEW_STRING'#g" jboss-beans.xml
Still your search expression contains special regexp characters, and using sed
like this is just waste of its abilities. I would write the expression like this:
sed -i 's/\(<.*webServiceHost.*jboss.bind.address.*>\)/<!--\1-->/' jboss-beans.xml
Of course you can make the match string more or less specific according to your needs. There is also other nice feature that can help. sed
allows to narrow editing operations to the lines matching a specific pattern. Your command could look like this:
sed -i '/webServiceHost/ s/^\(.*\)$/<!--\1-->/' jboss-beans.xml
Yes, you can grep
/dev/sda1
and /proc
but you probably don't want to. In more detail:
Yes, you can run grep the binary contents of /dev/sda1
. But, with modern large hard disks, this will take a very long time and the result is not likely to be useful.
Yes, you can grep the contents of /proc
but be aware that your computer's memory is mapped in there as files. On a modern computer with gigabytes of RAM, this will take a long time to grep and, again, the result is not likely to be useful.
As an exception, if you are looking for data on a hard disk with a damaged file system, you might run grep something /dev/sda1
as part of an attempt to recover the file's data.
Other problematic files in /dev
The hard disks and hard disk partitions under /dev
can be, if one has enough patience, grepped. Other files (hat tip: user2313067), however, may cause problems:
/dev/zero
is a file of infinite length. Fortunately, grep
(at least the GNU version) is smart enough to skip it:
$ grep something /dev/zero
grep: input is too large to count
/dev/random
and /dev/urandom
are also infinite. The command grep something /dev/random
will run forever unless grep
is signaled to stop.
It can be useful to grep /dev/urandom
when generating passwords. To get, for example, five random alphanumeric characters:
$ grep --text -o '[[:alnum:]]' /dev/urandom | head -c 10
G
4
n
X
2
This is not infinite because, after it has received enough characters, head
closes the pipe causing grep to terminate.
Infinite loops
"...links ... create infinite loops when traversed..."
Grep (at least the GNU version) is smart enough not to do that. Let's consider two cases:
With the -r
option, grep does not follow symbolic links unless they are explicitly specified on the command line. Hence, infinite loops are not possible.
With the -R
option, grep does follow symbolic links but it checks them and refuses to get caught in a loop. To illustrate:
$ mkdir a
$ ln -s ../ a/b
$ grep -R something .
grep: warning: ./a/b: recursive directory loop
Excluding problematic directories from grep -r
As an aside, grep
provides a limited facility to stop grep from searching certain files or directories. For example, you can exclude all directories named proc
, sys
, and dev
from grep's recursive search with:
grep --exclude-dir proc --exclude-dir sys --exclude-dir dev -r something /
Alternatively, we can exclude proc
, sys
, and dev
using bash's extended globs:
shopt -s extglob
grep -r something /!(proc|sys|dev)
Best Answer
I can answer at least the first question. If you're using Unix/Linux you can use tr
where \000 is the null char. You can also strip all non-printable chars as you can see on the example here: "Unix Text Editing: sed, tr, cut, od, awk"
Regarding your second question, I don't know which is your programming language but I'd search for uninitialized variables which could be end being printed to the output file.