I noticed that installing the grunt-cli did this. It looks like a symbolic link or something similar.
lrwxr-xr-x 1 root admin 39 Jan 9 2016 grunt -> ../lib/node_modules/grunt-cli/bin/grunt
lrwxr-xr-x 1 root admin 28 Nov 3 2015 heroku -> /usr/local/heroku/bin/heroku
-rwxrwxr-x 1 root wheel 23369552 Dec 23 2015 node
lrwxr-xr-x 1 root admin 38 Jan 10 2016 npm -> ../lib/node_modules/npm/bin/npm-cli.js
lrwxr-xr-x 1 a admin 64 Mar 22 2016 subl -> /Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl
-rwxr-xr-x 1 root wheel 75 Apr 28 06:32 vbox-img
-rwxr-xr-x 1 root wheel 77 Apr 28 06:32 vboxwebsrv
More importantly, why is it doing this?
/usr/local/bin/grunt -> /usr/local/lib/node_modules/grunt-cli/bin/grunt
Indeed, the -> indicates the file is a "symbolic link" ( aka "symlink" ) — the l in front of the permissions is also an indicator of it's type. Essentially filename a redirects to filename b at it's location ... a -> b.
You can create a symlink simply by doing:
$ ln -s <target> <original>
When creating a symlink it's the reverse of a -> b. ( In other words, while creating the symlink you would "link symbolically (ln -s) <target> (b) to <original> (a)" )...
Why /usr/local/bin/grunt goes to /usr/local/lib/node_modules/grunt-cli/bin/grunt is something you'd have to ask the developer, although my guess is that by doing:
$ grunt
...it's much more convenient than doing:
$ /usr/local/lib/node_modules/grunt-cli/bin/grunt
If the symlink wasn't indicated as it is in /usr/local/bin then you'd be using the latter...
Related
System:
Ubuntu 21.04 inside Virtual Box.
Running sudo apt install libfftw3-3 installs the fftw3 libs, but doesn't seem to create the symbolic links for the system to find them.
In the below terminal output, I don't see libfftw3.so listed anywhere, and the linker can't find it anywhere. Should I have expected the apt install command to take care of this for me? In the short term, should I just manually create a symbolic link? What link should I create? I presume I it should be something like:
sudo ln -s /usr/lib/x86_64-linux-gnu/libfftw3.so.3 /usr/lib/libfftw3.so
anything wrong with that?
Here's the terminal output:
>>> find /usr -name "*fftw*"
/usr/lib/x86_64-linux-gnu/libfftw3f.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f.so.3
/usr/lib/x86_64-linux-gnu/libfftw3.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.so.3
/usr/share/doc/libfftw3-3
/usr/share/doc/libfftw3-long3
/usr/share/doc/libfftw3-single3
/usr/share/doc/libfftw3-double3
>>> g++ test.cpp -o test -lfftw3 && ./test
/usr/bin/ld: cannot find -lfftw3
collect2: error: ld returned 1 exit status
>>> ls -l /usr/lib/x86_64-linux-gnu/*fftw*
lrwxrwxrwx 1 root root 22 Jul 3 10:40 libfftw3f_omp.so.3 -> libfftw3f_omp.so.3.5.8
-rw-r--r-- 1 root root 31176 Jun 5 2020 libfftw3f_omp.so.3.5.8
lrwxrwxrwx 1 root root 18 Jul 3 10:40 libfftw3f.so.3 -> libfftw3f.so.3.5.8
-rw-r--r-- 1 root root 2156872 Jun 5 2020 libfftw3f.so.3.5.8
lrwxrwxrwx 1 root root 26 Jul 3 10:40 libfftw3f_threads.so.3 -> libfftw3f_threads.so.3.5.8
-rw-r--r-- 1 root root 35368 Jun 5 2020 libfftw3f_threads.so.3.5.8
lrwxrwxrwx 1 root root 22 Jun 5 2020 libfftw3l_omp.so.3 -> libfftw3l_omp.so.3.5.8
-rw-r--r-- 1 root root 31176 Jun 5 2020 libfftw3l_omp.so.3.5.8
lrwxrwxrwx 1 root root 18 Jun 5 2020 libfftw3l.so.3 -> libfftw3l.so.3.5.8
-rw-r--r-- 1 root root 899392 Jun 5 2020 libfftw3l.so.3.5.8
lrwxrwxrwx 1 root root 26 Jun 5 2020 libfftw3l_threads.so.3 -> libfftw3l_threads.so.3.5.8
-rw-r--r-- 1 root root 35368 Jun 5 2020 libfftw3l_threads.so.3.5.8
lrwxrwxrwx 1 root root 21 Jun 5 2020 libfftw3_omp.so.3 -> libfftw3_omp.so.3.5.8
-rw-r--r-- 1 root root 31176 Jun 5 2020 libfftw3_omp.so.3.5.8
lrwxrwxrwx 1 root root 17 Jun 5 2020 libfftw3.so.3 -> libfftw3.so.3.5.8
-rw-r--r-- 1 root root 2115912 Jun 5 2020 libfftw3.so.3.5.8
lrwxrwxrwx 1 root root 25 Jun 5 2020 libfftw3_threads.so.3 -> libfftw3_threads.so.3.5.8
-rw-r--r-- 1 root root 35368 Jun 5 2020 libfftw3_threads.so.3.5.8
As a reluctant Mac user, I am routinely frustrated by things that should be very simple. Finder is one of those. When trying to open an XML file from Firefox, I am asked what application I whish to open it with. Obviously MacVim. To do that, I need to navigate to /usr/local/bin/gvim which is a symlink to /Cellar, since it was installed with HomeBrew. However, when I select "Open with" and click "Choose", the Finder comes up and defaults to Applications. It's not in there, I just want to navigate directly to the symlink. Switching to "Macintosh HD" (also known as "/" to a more refined audience) only displays Application, Library, System, and Users. Where is everything else? Where is /usr, /bin, /etc? As a user, this seems disingenuous. It's not an accurate representation of my location in the filesystem. Sorry, this is a bit of a rant, but also a legitimate question. How do I display these all the time?
The UNIX (lowercase) directories are hidden from view, intentionally, through a special "hidden" flag. You can see those in ls -lO:
Chimera:~ morpheus$ ls -lO /
total 14
drwxrwxr-x+ 59 root admin sunlnk 1888 Sep 23 16:46 Applications
drwxr-xr-x+ 65 root wheel sunlnk 2080 Mar 20 2020 Library
drwxr-xr-x 2 root wheel hidden 64 Sep 30 2018 Network
drwxr-xr-x# 5 root wheel restricted 160 Sep 21 2018 System
drwxr-xr-x 7 root admin - 224 Mar 20 2020 Users
drwxr-xr-x# 8 root wheel hidden 256 Sep 23 21:17 Volumes
drwxr-xr-x# 37 root wheel restricted,hidden 1184 Mar 27 2019 bin
drwxrwxr-t# 2 root admin hidden 64 Feb 8 2019 cores
dr-xr-xr-x 3 root wheel hidden 4821 Aug 30 19:38 dev
lrwxr-xr-x# 1 root wheel restricted,hidden 11 Sep 30 2018 etc -> private/etc
dr-xr-xr-x 2 root wheel hidden 1 Sep 24 07:59 home
-rw-r--r-- 1 root wheel hidden,compressed 313 Aug 17 2018 installer.failurerequests
drwxr-xr-x 2 root wheel - 64 Oct 3 2018 mnt
drwxr-xr-x 2 root wheel - 64 Jan 21 2018 mnt1
dr-xr-xr-x 2 root wheel hidden 1 Sep 24 07:59 net
drwxr-xr-x 6 root wheel sunlnk,hidden 192 Sep 30 2018 private
drwxr-xr-x# 64 root wheel restricted,hidden 2048 Mar 27 2019 sbin
lrwxr-xr-x# 1 root wheel restricted,hidden 11 Sep 30 2018 tmp -> private/tmp
drwxr-xr-x# 9 root wheel restricted,hidden 288 Sep 21 2018 usr
lrwxr-xr-x# 1 root wheel restricted,hidden 11 Sep 30 2018 var -> private/var
Additionally, Finder will not display hidden "." files, the same way ls -l needs to be "persuaded" using -a (try "ls -lOa /", omitted here for brevity).
Pressing the apple key along with shift and '.' will display everything. To make this the default behavior:
defaults write com.apple.finder AppleShowAllFiles YES
In case you're interested in the rationale - it dates back to NeXTSTEP (the progenitor to MacOS X and later as we know it now), which wanted to provide a user interface to its own (Uppercase first letter) directories, while hiding those of the underlying UNIX (BSD layer), seeing as non-root users have nothing to look for there, anyway (and most users have no knowledge of terminal/shell).
I am trying run docker inside WSL (am running Ubuntu in WSL). Also am new to docker. The doc says:
To get the best out of the file system performance when bind-mounting files:
Store source code and other data that is bind-mounted into Linux containers (i.e., with docker run -v <host-path>:<container-path>) in the Linux filesystem, rather than the Windows filesystem.
Linux containers only receive file change events (“inotify events”) if the original files are stored in the Linux filesystem.
Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users (where /mnt/c is mounted from Windows).
Instead, from a Linux shell use a command like docker run -v ~/my-project:/sources <my-image> where ~ is expanded by the Linux shell to $HOME.
I also came across following:
Run sudo docker run -v "$HOME:/host" --name "[name_work]" -it docker.repo/[name]. With, [$HOME:/host], you can access your home directory in /host dir in docker image. This allows you to access your files on the local machine inside the docker. So you can edit your source code in your local machine using your favourite editor and run them directly inside the docker. Make sure that you have done this correct. Otherwise, you may need to copy files from the local machine to docker, for each edit (a painful job).
I am not able to understand the format of parameter passed to -v option and what it does. I am thinking that it will allow to access Ubuntu directories inside docker. So $HOME:/host will map Ubuntu's home directory to /host inside.
Q1. But what is /host?
Q2. Can I do what is stated by above two quotes together? I mean what they are saying is compatible? I guess yes. What all its saying is I should not mount from windows director like /mnt/<driveletter>/.... If I am mounting linux directory like $USER/... then it will give better performance, right?
I tried out running it to understand it:
~$ docker run -v "$HOME:/host" --name "mydokr" -it docker.repo.in/dokrimg
root#f814974a1cfb:/home# ls
root#f814974a1cfb:/home# ll
total 8
drwxr-xr-x 2 root root 4096 Apr 15 11:09 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
root#f814974a1cfb:/home# pwd
/home
root#f814974a1cfb:/home# cd ..
root#f814974a1cfb:/# ll
total 64
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
-rwxr-xr-x 1 root root 0 Sep 22 07:16 .dockerenv*
lrwxrwxrwx 1 root root 7 Jul 3 01:56 bin -> usr/bin/
drwxr-xr-x 2 root root 4096 Apr 15 11:09 boot/
drwxr-xr-x 5 root root 360 Sep 22 07:16 dev/
drwxr-xr-x 1 root root 4096 Sep 22 07:16 etc/
drwxr-xr-x 2 root root 4096 Apr 15 11:09 home/
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 host/
lrwxrwxrwx 1 root root 7 Jul 3 01:56 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 Jul 3 01:56 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 Jul 3 01:56 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root 10 Jul 3 01:56 libx32 -> usr/libx32/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 media/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 mnt/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 opt/
dr-xr-xr-x 182 root root 0 Sep 22 07:16 proc/
drwx------ 1 root root 4096 Aug 24 03:54 root/
drwxr-xr-x 1 root root 4096 Aug 11 10:24 run/
lrwxrwxrwx 1 root root 8 Jul 3 01:56 sbin -> usr/sbin/
drwxr-xr-x 2 root root 4096 Jul 3 01:57 srv/
dr-xr-xr-x 11 root root 0 Sep 22 03:32 sys/
-rw-r--r-- 1 root root 1610 Aug 24 03:56 test_logPath.log
drwxrwxrwt 1 root root 4096 Aug 24 03:57 tmp/
drwxr-xr-x 1 root root 4096 Aug 11 10:24 usr/
drwxr-xr-x 1 root root 4096 Jul 3 02:00 var/
root#f814974a1cfb:/home# cd ../host
root#f814974a1cfb:/host# ll
total 36
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 ./
drwxr-xr-x 1 root root 4096 Sep 22 07:16 ../
-rw-r--r-- 1 1000 1001 220 Sep 22 03:38 .bash_logout
-rw-r--r-- 1 1000 1001 3771 Sep 22 03:38 .bashrc
drwxr-xr-x 3 1000 1001 4096 Sep 22 04:56 .docker/
drwxr-xr-x 2 1000 1001 4096 Sep 22 03:38 .landscape/
-rw-r--r-- 1 1000 1001 0 Sep 22 03:38 .motd_shown
-rw-r--r-- 1 1000 1001 921 Sep 22 04:52 .profile
-rw-r--r-- 1 1000 1001 0 Sep 22 03:44 .sudo_as_admin_successful
drwxr-xr-x 5 1000 1001 4096 Sep 22 04:52 .vscode-server/
-rw-r--r-- 1 1000 1001 183 Sep 22 04:52 .wget-hsts
So I am not getting whats happening here. I know docker has its own file system.
Q3. Is is that, what am finding at /home and /host is indeed container's own file system?
Q4. Also, what happened to -v $HOME:/host here?
Q5. How can I do as stated by 2nd quote:
This allows you to access your files on the local machine inside the docker. So you can edit your source code in your local machine using your favourite editor and run them directly inside the docker.
Q6. How do I connect vscode to this container? From WSL-Ubuntu, I could just run code . to launch vscode. But the same does not seem to work here:
root#f814974a1cfb:/home# code .
bash: code: command not found
This link says:
A devcontainer.json file can be used to tell VS Code how to configure the development container, including the Dockerfile to use, ports to open, and extensions to install in the container. When VS Code finds a devcontainer.json in the workspace, it automatically builds (if necessary) the image, starts the container, and connects to it.
But I guess this says starting up creating new container form vscode. But not connecting to already existing container. I am not able to find my dockercontainer.json. I downloaded this container image using docker pull.
How to remove the following message:
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
Every time I open a Terminal it appears. I upgraded from Ubuntu 14.04 LTS to 16.04 LTS and it seems that update made that.
I am using bash.
I googled that and found this command:
$ touch ~/.hushlogin
Execute the below command and close the terminal. The message will be remove from the terminal.
sudo apt-get update
atleast my ubuntu 14.04 machine will display(or run) all the script in /etc/update-motd.d(motd => message of the day) directory.
ll /etc/update-motd.d/
total 40
drwxr-xr-x 2 root root 4096 Sep 27 2014 ./
drwxr-xr-x 109 root root 4096 Nov 30 10:27 ../
-rwxr-xr-x 1 root root 1220 Feb 20 2014 00-header*
-rwxr-xr-x 1 root root 1358 Feb 20 2014 10-help-text*
lrwxrwxrwx 1 root root 46 Sep 27 2014 50-landscape-sysinfo -> /usr/share/landscape/landscape-sysinfo.wrapper*
-rwxr-xr-x 1 root root 334 Sep 27 2014 51-cloudguest*
-rwxr-xr-x 1 root root 149 Aug 22 2011 90-updates-available*
-rwxr-xr-x 1 root root 299 Aug 21 2014 91-release-upgrade*
-rwxr-xr-x 1 root root 111 Mar 27 2014 97-overlayroot*
-rwxr-xr-x 1 root root 142 Aug 22 2011 98-fsck-at-reboot*
-rwxr-xr-x 1 root root 144 Aug 22 2011 98-reboot-required*
The scipt with lowest number is gonna execute first 00-header*
I'm running Max OSX 10.9.3 and I'm trying to setup an SSHFS file-share between my MacBook Pro and a remote file system. However, when I try to do it, it doesn't work.
Strangely enough, it makes the target directory disappear. Has anyone else seen this happen? Is it a bug?
First see that I can ssh normally into the target machine:
% ssh remoteuser#XXX.XXX.XXX.XXX # <--- SSH to remote system works! See below.
remoteuser#XXX.XXX.XXX.XXX % ls -altr remoteDir
total 8
drwxr-xr-x 26 remoteuser remoteuser 4096 Jun 22 01:00 ..
drwxrwxrwx 2 remoteuser remoteuser 4096 Jun 22 01:08 .
remoteuser#XXX.XXX.XXX.XXX % exit
% # <--- Logged out of remote system
Next, I create a directory locally and verify it was created:
% pwd
/mnt
% ls
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 2 root admin 68 Jun 23 08:11 ./
% sudo mkdir share1
% ls
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 4 root admin 136 Jun 23 08:50 ./
drwxr-xr-x 2 root admin 68 Jun 23 08:50 share/
Now I try to setup the SSHFS share:
% sudo sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
remoteuser#XXX.XXX.XXX.XXX's password:
%
Ok. It seems to have worked. No errors. So let's see the share we created, shall we?
% ls
ls: share1: No such file or directory
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 3 root admin 102 Jun 23 08:12 ./
What? Not only is the File Sharing not working, but the share1 directory seems to have vanished! (Although the file system seems to know it is missing, which is weird).
Where did /mnt/share1 go and how do I setup this SSHFS?
SSHFS doesn't come with OS X AFAIK, so you should mention how you installed it. But I'm guessing sshfs is designed to be used with fstab or mount rather than be called directly. Try something like:
mount -t sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1