The problem with perl -i and sed -i is that they try to create a backup/temporary file in /etc, and $USER doesn't have write permission on /etc. You could:

cp /etc/myfile $HOME/myfile sed -i ... $HOME/myfile cp $HOME/myfile /etc/myfile 

This will leave the backup file in $HOME. Backup files (old configs) don't belong in /etc.

The problem with perl -i and sed -i is that they try to create a backup/temporary file in /etc, and $USER doesn't have write permission on /etc. You could:

cp /etc/myfile $HOME/myfile sed -i ... $HOME/myfile cp $HOME/myfile /etc/myfile 

This will leave the backup file in $HOME. Backup files (old configs) don't belong in /etc.

Or, if you set up the VISUAL (for GUI terminals) and EDITOR (for non-GUI terminals) environment variables to point to your favorite editor (in ~/.bashrc), you can use the sudoedit command to edit files to which $USER has no normal access.

After sudo authentication, sudoedit does it thusly:

1. As root, sudoedit makes a temporary copy of the file-to-be-edited.
2. As $USER, invokes $VISUAL in the GUI environment, $EDITOR in non-GUI, on the temporary file.
3. As root, copies the temporary file back to the file-to-be-edited, if the editor succeeded.

The problem with perl -i and sed -i is that they try to create a backup file in /etc, and $USER doesn't have write permission on /etc. You could:

cp /etc/myfile $HOME/myfile sed -i ... $HOME/myfile cp $HOME/myfile /etc/myfile 

This will leave the backup file in $HOME. Backup files (old configs) don't belong in /etc.

The problem with perl -i and sed -i is that they try to create a backup/temporary file in /etc, and $USER doesn't have write permission on /etc. You could:

cp /etc/myfile $HOME/myfile sed -i ... $HOME/myfile cp $HOME/myfile /etc/myfile 

This will leave the backup file in $HOME. Backup files (old configs) don't belong in /etc.