I connect to a remote computer thru VNC and use Konsole for my work. Konsole is version 2.3.3 using KDE 4.3.4. I have these two aliases:
alias ll 'ls -haltr; pwd'
alias cd 'cd \!*; ll'
which I observed to have the following behavior:
When path exists, it will cd to it and also do the ll alias
When path doesn't exist, it will simply say the path doesn't exist and won't do the ll anymore
Example:
Path exists
[10] % cd foo
total 14K
-rw-r----- 1 user group 913 Jun 3 2014 readme
-rw-r----- 1 user group 1.2K Dec 3 2020 report.txt
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user/foo
[11] %
Path doesn't exist
[10] % cd nowhere
nowhere: No such file or directory.
[11] %
Now our department has transferred to another division and we've just started to connect remotely thru Exceed TurboX. I still use Konsole but the version is now 2.10.5 using KDE 4.10.5. I copied over the same two aliases, but I'm now observing a different behavior:
When path exists, it will cd to it and also do the ll alias (basically same as #1 above)
When path doesn't exist, it will attempt to cd AND still do the ll (different as #2 above)
So for #2, here's how it looks like:
[10] % cd nowhere
nowhere: No such file or directory.
total 120K
-rw-r----- 1 user group 272 Jan 6 2021 .cshrc
-rw-r----- 1 user group 1.2K Jan 6 2021 .alias
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user
[11] %
I would like to know how to get behavior #2 of the previous working environment to this current working environment.
I've added the information on the Konsole and KDE versions because if the behavior is due to the version and there's no workaround, then I'll just be sad for the rest of my life working in this new remote desktop env. ^_^
I'm currently exploring a "check first if the path exists before doing ll" but to no avail. :'(
Edit:
The shell I'm using is tcsh
% printenv SHELL in both environments showed /bin/tcsh
And in addition:
Old environment
% echo $version
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec
New environment
% echo $version
3
The information in the question is still not sufficient to find out why tcsh behaves differently in the two working environments.
The alias defines a sequence of commands (cd followed by ll) without any condition.
alias cd 'cd \!*; ll'
On one system the execution of the alias seems to stop if the cd command reports an error for currently unknown reasons.
The correct way to prevent the execution of ll after a failed cd command would be the conditional execution of the ll command, e.g.
alias cd 'cd \!* && ll'
The decade long advice is: do not use aliases, use functions.
ll() { ls -haltr "$#" && pwd; }
cd() { cd "$#" && ll; }
in a buildroot environment I added one user to the group wheel. Now I can execute commands with the root's privileges using sudo.
It seems it works but when I try to export a pin on my RPi I always get Permission denied:
rpi:~$ sudo echo 4 > /sys/class/gpio/export
sh: can't create /sys/class/gpio/export: Permission denied
Here the contents of that directory:
rpi:~$ ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 Jan 1 00:00 export
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
--w------- 1 root root 4096 Jan 1 00:00 unexport
Isn't enough to get the root's privilege with sudo to write in the export file? I'm afraid about the owner and groups. In fact if I type:
rpi:~$ sudo chmod a+w /sys/class/gpio/*
then I can successfully export the pin. But I don't know if this is the best way to do this.
When you run the command sudo echo 4 > /sys/class/gpio/export, it first executes sudo echo 4 which runs echo with elevated privileges (which is kind of pointless). Then the result is passed by the shell (not by echo) to a new command of /sys/class/gpio/export, which because it is a new command it isn't executed with elevated privileges.
There is a Unix.SE question here which explains this and the options.
In summary of that link you should be able to do something like:
sudo sh -c 'echo 4 > /sys/class/gpio/export'
I am working on Solaris 10 machine. In that i cannot able to untar my file. Logs are given below. Anyone please suggest what may be the issue? I can able to create tar file but unable to untar. :(
bash-3.2# ls -lrth ConfigCheck-120614-KL.out*
-rw-r--r-- 1 root root 144K Jun 12 17:15 ConfigCheck-120614-KL.out
-rwxrwxrwx 1 root root 146K Jun 16 16:49 ConfigCheck-120614-KL.out.tar
bash-3.2# tar xvf ConfigCheck-120614-KL.out.tar
tar: extract not authorized
bash-3.2# tar tvf ConfigCheck-120614-KL.out.tar
-rw-r--r-- 0/0 147377 Jun 12 17:15 2014 ConfigCheck-120614-KL.out
Solaris 11 tar will fail with that error message if you are running as uid 0 but do not have the Media Restore profile set up in the RBAC configuration.
Unless you're trying to restore from backup, you should normally be untarring files as a normal user, not root, to avoid accidentally overwriting critical system files.
I have 4 files: the naming convention is as follows:
hello.account.sub1.001
hello.account.sub2.001
hello.account.sub3.001
hello.account.sub4.001
If I use ls -l hello.account*001 to search files, no problem exists.
However, problem exists when using ls -l hello.account.*.001
The system complains that No such file or directory
I assume the system considers hello.account.*.001 is a single file.
This interests me so I ask: how can you search the file if a full stop is specified as searching criteria?
Many Thanks
Filename globbing is done by the shell, before actually executing the command (such as ls in your case). The following works:
$ ksh --version
version sh (AT&T Research) 93t+ 2010-06-21
$ ls -l hello.account.*.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub1.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub2.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub3.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub4.001
while the following does not:
$ ls -l "hello.account.*.001"
ls: hello.account.*.001: No such file or directory
The reason is that in the first case, the shell expands the file name pattern before executing ls - ls will then see four different file names passed as arguments.
In the second case, since the file name pattern is escaped with double quotes, ls gets the pattern itself passed (which ls does not further expand - it looks for a file with the name hello.account.*.001)
Does any operating system provide a mechanism (system call — not command line program) to change the pathname referenced by a symbolic link (symlink) — other than by unlinking the old one and creating a new one?
The POSIX standard does not. Solaris 10 does not. MacOS X 10.5 (Leopard) does not. (I'm tolerably certain neither AIX nor HP-UX does either. Judging from this list of Linux system calls, Linux does not have such a system call either.)
Is there anything that does?
(I'm expecting that the answer is "No".)
Since proving a negative is hard, let's reorganize the question.
If you know that some (Unix-like) operating system not already listed has no system call for rewriting the value of a symlink (the string returned by readlink()) without removing the old symlink and creating a new one, please add it — or them — in an answer.
Yes, you can!
$ ln -sfn source_file_or_directory_name softlink_name
AFAIK, no, you can't. You have to remove it and recreate it. Actually, you can overwrite a symlink and thus update the pathname referenced by it:
$ ln -s .bashrc test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc
$ ln -s .profile test
ln: creating symbolic link `test': File exists
$ ln -s -f .profile test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profile
EDIT: As the OP pointed out in a comment, using the --force option will make ln perform a system call to unlink() before symlink(). Below, the output of strace on my linux box proving it:
$ strace -o /tmp/output.txt ln -s -f .bash_aliases test
$ grep -C3 ^unlink /tmp/output.txt
lstat64("test", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test") = -1 EEXIST (File exists)
unlink("test") = 0
symlink(".bash_aliases", "test") = 0
close(0) = 0
close(1) = 0
So I guess the final answer is "no".
EDIT: The following is copied from Arto Bendiken's answer over on unix.stackexchange.com, circa 2016.
This can indeed be done atomically with rename(2), by first creating the new symlink under a temporary name and then cleanly overwriting the old symlink in one go. As the man page states:
If newpath refers to a symbolic link the link will be overwritten.
In the shell, you would do this with mv -T as follows:
$ mkdir a b
$ ln -s a z
$ ln -s b z.new
$ mv -T z.new z
You can strace that last command to make sure it is indeed using rename(2) under the hood:
$ strace mv -T z.new z
lstat64("z.new", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
lstat64("z", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
rename("z.new", "z") = 0
Note that in the above, both mv -T and strace are Linux-specific.
On FreeBSD, use mv -h alternately.
Editor's note: This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.
It is not necessary to explicitly unlink the old symlink. You can do this:
ln -s newtarget temp
mv temp mylink
(or use the equivalent symlink and rename calls). This is better than explicitly unlinking because rename is atomic, so you can be assured that the link will always point to either the old or new target. However this will not reuse the original inode.
On some filesystems, the target of the symlink is stored in the inode itself (in place of the block list) if it is short enough; this is determined at the time it is created.
Regarding the assertion that the actual owner and group are immaterial, symlink(7) on Linux says that there is a case where it is significant:
The owner and group of an existing symbolic link can be changed using
lchown(2). The only time that the ownership of a symbolic link matters is
when the link is being removed or renamed in a directory that has the sticky
bit set (see stat(2)).
The last access and last modification timestamps of a symbolic link can be
changed using utimensat(2) or lutimes(3).
On Linux, the permissions of a symbolic link are not used in any operations;
the permissions are always 0777 (read, write, and execute for all user
categories), and can't be changed.
Just a warning to the correct answers above:
Using the -f / --force Method provides a risk to lose the file if you mix up source and target:
mbucher#server2:~/test$ ls -la
total 11448
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:27 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
-rw-r--r-- 1 mbucher www-data 7582480 May 25 15:27 otherdata.tar.gz
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ln -s -f thesymlink otherdata.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ls -la
total 4028
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:28 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
lrwxrwxrwx 1 mbucher www-data 10 May 25 15:28 otherdata.tar.gz -> thesymlink
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
Of course this is intended, but usually mistakes occur. So, deleting and rebuilding the symlink is a bit more work but also a bit saver:
mbucher#server2:~/test$ rm thesymlink && ln -s thesymlink otherdata.tar.gz
ln: creating symbolic link `otherdata.tar.gz': File exists
which at least keeps my file.
Wouldn't unlinking it and creating the new one do the same thing in the end anyway?
Just in case it helps: there is a way to edit a symlink with midnight commander (mc).
The menu command is (in French on my mc interface):
Fichier / Éditer le lien symbolique
which may be translated to:
File / Edit symbolic link
The shortcut is C-x C-s
Maybe it internally uses the ln --force command, I don't know.
Now, I'm trying to find a way to edit a whole lot of symlinks at once (that's how I arrived here).
Technically, there's no built-in command to edit an existing symbolic link. It can be easily achieved with a few short commands.
Here's a little bash/zsh function I wrote to update an existing symbolic link:
# -----------------------------------------
# Edit an existing symbolic link
#
# #1 = Name of symbolic link to edit
# #2 = Full destination path to update existing symlink with
# -----------------------------------------
function edit-symlink () {
if [ -z "$1" ]; then
echo "Name of symbolic link you would like to edit:"
read LINK
else
LINK="$1"
fi
LINKTMP="$LINK-tmp"
if [ -z "$2" ]; then
echo "Full destination path to update existing symlink with:"
read DEST
else
DEST="$2"
fi
ln -s $DEST $LINKTMP
rm $LINK
mv $LINKTMP $LINK
printf "Updated $LINK to point to new destination -> $DEST"
}
You can modify the softlink created once in one of the two ways as below in Linux
one is where you can remove existing softlink with rm and again create new softlink with ln -s command .
However this can be done in one step , you can replace existing softlink with updated path with "ln -vfns Source_path Destination_path" command.
Listing initial all files in directory
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
$
Create softlink test for test_script with ln -s command.
$ ln -s test_script test
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
lrwxrwxrwx. 1 root root 11 Feb 27 18:58 test -> test_script
$
Update softlink test with new directory test_script/softlink with single command
$ ln -vfns test_script/softlink/ test
'test' -> 'test_script/softlink/'
$
List new softlink location
$ ls -lrt
lrwxrwxrwx. 1 root root 21 Feb 27 18:59 test -> test_script/softlink/
$
ln --help
-v, --verbose print name of each linked file
-f, --force remove existing destination files
-n, --no-dereference treat LINK_NAME as a normal file if it is a symbol
-s, --symbolic make symbolic links instead of hard links