sed -i -e "s#^ filename:.*.infos.log# filename:${log_dir}/infos.log#" ${default_config_dir}/logging.conf
I tried to execute the above command but it always tells me that
sed: can't read /logging.conf: No such file or directory
even though there is a file in that location with that name.
The leading slash in your message is a clear indication that the variable ${default_config_dir} is either unset or empty.
Related
So, I am trying to delete the first 23 lines of many .txt files. This is what I am currently doing:
sed -i -e 1,23d * .txt
but it gives me a weird error:
sed: 1: "1,23": command expected
I have no idea what to do. _
Like this:
sed -i -e '1,23d' *.txt
# ^ mandatory 'd'
# ^
# no space between * and .txt
The original question (before editing) showed:
sed -i -e 1,23d * .txt
but it gives me a weird error:
sed: Applications: in-place editing only works for regular files
The space between * and .txt was a mistake, but is an explanation of the weird error: It looks for all files as well as for the hidden file .txt.
Linux considers the directory Application as a file, but sed does not work on files.
The directory Application suggests that the files might come from Windows.
Another question is why echo *.txt don't show the txt files Mia was expecting. A logical explanation is that the files originated from Windows and Mia doesn't know that Linux is case sensitive. Files like A.TXT and b.Txt don't match *.txt.
When all txt files end with TXT, you can do
sed -i -e '1,23d' *.TXT
When you have a mix of upper- and lower case, the easiest way is
sed -i -e '1,23d' *.[tT][xX][tT]
I am trying replace value in a config file with sed in cshell.
However it gives me the error:
sed: 1: "/usr/local/etc/raddb/mo ...": extra characters at the end of l command
I am trying the following command:
sed -i "s/private_key_password = .*/private_key_password = test/" /usr/local/etc/raddb/mods-available/eap
I have looked at examples of sed to do this but they all look similar with what I am doing, what is going wrong here?
FreeBSD sed requires an argument after -i to rename the original file to. For example sed -i .orig 's/../../' file will rename he original file to file.orig, and save the modified file to file.
This is different from GNU sed, which doesn't require an argument for the -i flag. See sed(1) for the full documentation. This is one of those useful extensions to the POSIX spec which is unfortunately implemented inconsistently.
Right now, the "s/private_key_password = .*/private_key_password = test/" parts gets interpreted as an argument to -i, and /usr/local/etc/raddb/mods-available/eap gets interpreted as the command. Hence the error.
So you want to use:
sed -i .orig "s/private_key_password = .*/private_key_password = test/" /usr/local/etc/raddb/mods-available/eap
You can then check if the changes are okay with diff and remove /usr/local/etc/raddb/mods-available/eap.orig if they are.
How can we use wildcard characters while running system command in Perl Script.
For example using *.src to edit a file with sed - something like :
system("sed -i -e 's/foo/bar/g' $baseDirPath/*.src");
It gives an error: sed: can't read /home/test/*.src: Not a Directory
Here, $baseDirPath is initialized to /home/test
Try to chomp the variable $baseDirPath before using it, As the line you have written should just work.
Perl’s -i switch appears to modify read-only files:
$ echo 'foobar' > tmp.txt
$ chmod -w tmp.txt
$ perl -pi -w -e 's/foobar/FOOBAR/' tmp.txt
$ cat tmp.txt
FOOBAR
This is unexpected, as the command should not have been able to modify the file per its permissions. Expectedly, trying to update it via other means fails:
$ echo 'barbaz' > tmp.txt
-bash: tmp.txt: Permission denied
Why is Perl modifying read-only files (and how?), and, most importantly: how can I get Perl to not do so?
The only somewhat informative resource I can find on this is in the Perl FAQ:
The permissions on a file say what can happen to the data in that file. … If you try to write to the file, the permissions of the file govern whether you're allowed to.
Which ultimately seems like its saying it shouldn’t be able to write to it, since the file system says you cannot.
Filter #ARGV in a BEGIN block:
perl -pi -e 'BEGIN{#ARGV=grep{-w $_}#ARGV} s/foobar/FOOBAR/' files
Now if none of the files on the command line are writable, #ARGV will be empty and the ARGV filehandle will try to read from STDIN. I can think of two ways to keep this from being a problem:
Close STDIN in the BEGIN block, too
perl -pi -e 'BEGIN{close STDIN;#ARGV=grep{-w $_}#ARGV}s/foobar/FOOBAR/' files
Always call this one-liner redirecting input from /dev/null
perl -pi -e 'BEGIN{#ARGV=grep{-w $_}#ARGV}s/foobar/FOOBAR/' files < /dev/null
See the documentation in perlrun:
renaming the input file, opening the output file by the original name, and selecting that output file as the default for print() statements
(...)
For a discussion of issues surrounding file permissions and -i, see "Why does Perl let me
delete read-only files? Why does -i clobber protected files? Isn't this a bug in Perl?" in
perlfaq5.
From perlrun:
-i
specifies that files processed by the <> construct are to be edited in-place. It does this by renaming the input file, opening the output file by the original name, and selecting that output file as the default for print() statements.
So it is doesn't really modify the file. It moves the file out of the way (which requires directory write permissions, not file write permissions) and then creates a new one with the old name.
how can I get Perl to not do so?
I don't think you can when you use -i.
I have a sed command that works just fine if I let the output get sent to stdout
sed s/defaultFedoraColor/grey/ stuff.js
however, if I try to change the file in place by add the -i flag
sed -i s/defaultFedoraColor/grey/ stuff.js
I get the error message of
sed: 1: "stuff.js": unterminated substitute pattern
Why would the flag change the legitimacy of my substitution pattern?
The -i flag takes a parameter! This parameter is the backup suffix used for the file being manipulated. (Presumably, a backup of the original file is made with the given suffix.) Therefore, your pattern has become the parameter for -i and sed tries to interpret "stuff.js" as the pattern.
Edit: I'm not experiencing this erroneous behaviour at all, though, but that's what a reading of the manpage would suggest to be the issue.
Another edit: Perhaps you want to simply add quotes around the pattern as suggested