New answers tagged

1

You need to delete your local libgmp completely: rm /usr/local/lib/libgmp.so* There's no need to run ldconfig afterwards. ldconfig makes sure the appropriate symlinks are present; libgmp.so.10 is a symlink to the latest library with that soname (run ls -l /usr/local/lib/libgmp.so* before deleting the files to see what I mean). Previously you deleted that ...


1

cron intentionally runs with a limited environment (including a restricted path, it does not have the same path as your standard shell). You either need to run a script (including the full path to the script) which then sets a path variable internally, or you need to set the path in the crontab line itself. One example of that is, 12 0 * * * (export ...


0

Use the -n option to avoid creating a directory. This will overwrite an existing symbolic link, but not create a link inside a directory that's pointed to by an existing symlink. ln -sn A a ln -n isn't POSIX but exists on GNU coreutils, BusyBox and *BSD (including OSX).


1

If all you're looking for is a single conditional test for a single command, you don't need an if statement—just use a list. According to LESS=+/Lists man bash: A list is a sequence of one or more pipelines separated by one of the operators ;, &, &&, or ||, and optionally terminated by one of ;, &, or <newline>. ... An ...


0

This related question, provides a way to identify a recursive symbolic link using the find command: $ find -L . . ./a ./a/b ./a/b/c ./a/b/c/d find: File system loop detected; `./a/b/c/d/e' is part of the same file system loop as `./a/b'. find: `./a/b/e': Too many levels of symbolic links


0

The symbolic link is just a pointer to a file / folder, like a shortcut. It will always have lrwxrwxrwx permissions. As pointed in another answer, the target permissions will be in effect. In contrary with this, a hard link is directory entry (a file) pointing to the same inode. Even if you change the name of the other file, a hardlink still points to the ...


2

Symlinks aren't copies of files, they're essentially pointers which point at the same file. That means for example, that you can't do anything about permissions, if you can't access the original file then no matter what you do with the symlink, you can't get around that. Also, they are always 'in sync' because they always point directly to the same file.


4

A symbolic link is just a reference to the actual file. There is no synchronization or something like that. If you look at the ls output for a symbuolic link you generally see something like: ls -l /bin/bzcmp lrwxrwxrwx 1 root root 6 jul 9 2014 /bin/bzcmp -> bzdiff As you can see the file /bin/bzcmp is just 6 bytes in size which happens to be ...


-1

Given that you get the error Not a directory, it is obvious that the symlink in the tar archive is lib/jre/ -> lib/jre1.8.0_46 which is different from what you tell us in your text. If gtar does not complain about that link, it is broken. Unfortunately, you did not give sufficient information about your constraints. We need to know: what type of ...


0

WORKSFORME on Ubuntu 15.10. What are you on? Are you sure you are using bash and not zsh? Maybe just maybe : echo 'set mark-directories on' >> ~/.inputrc echo 'export INPUTRC=~/.inputrc' >> ~/.bashrc


2

You can use bind mount to simulate hard linking directories sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory


0

I've seen the behavior you describe before, but testing it now I can create symlinks just fine on an sshfs-mounted directory: $ touch T $ ln -s T L $ ls -l T L lrwxrwxrwx 1 user user 1 Apr 9 16:10 L -> T -rw-rw-r-- 1 user user 0 Apr 9 16:10 T $ echo hello >> L $ cat T hello $ pwd /home/user/oak/tmp $ mount | grep oak user@oak: on /home/user/oak ...


2

If the software root is using can be configured to do "evil" stuff (or to display information in some unexpected way so that the root user does "evil" stuff out of not-knowing or false knowledge) by the config file, then that is a viable attack. In general, you weaken security, if access rights to edit ~/<configfile> can be more easily gained for that ...



Top 50 recent answers are included