When I run ls command on MacOS I see the line which contains a -> symbol. I cannot find a way to describe it.
lrwxr-xr-x 1 root wheel 21 Feb 18 2014 libBSDPClient.dylib -> libBSDPClient.A.dylib
What does it mean? And how can I call it?
The -> in the output of ls indicates a symbolic link (aka soft link). The part on the left is the name of the symlink, and the part on the right is its target. So in your example:
libBSDPClient.dylib -> libBSDPClient.A.dylib
There is a "file" libBSDPClient.dylib which is a link to libBSDPClient.A.dylib (in the same directory, and which may not actually exist).
As for your question about how to "call" it, well, you don't "call" shared objects, but you can "load" them in a running program by the usual mechanisms, such as runtime dynamic linking or explicitly via dlopen().
Related
I am creating my dot files following this tutorial. It successfully works for emacs.d.
Since I am using NixOS, I tried doing exactly the same steps with symlink creation for the configuration.nix file. Thus, I did:
1 - On terminal:
[pedro#system:/etc/nixos]$ sudo mv /etc/nixos/configuration.nix ~/.dotfiles/
2 - Then:
[pedro#system:/etc/nixos]$ ln -sf ~/.dotfiles/configuration.nix configuration.nix~
3 - It seems to work fine, as I do:
[pedro#system:/etc/nixos]$ ls -la
total 12
drwxr-xr-x 2 root root 4096 Dec 1 21:41 .
drwxr-xr-x 32 root root 4096 Dec 1 22:00 ..
lrwxrwxrwx 1 root root 39 Dec 1 21:41 configuration.nix~ -> /home/pedro/.dotfiles/configuration.nix
-rw-r--r-- 1 root root 842 Nov 12 17:40 hardware-configuration.nix
After doing some editions and saving the changes, I can't do nixos-rebuild switch, though. It throws an error:
[pedro#system:/etc/nixos]$ sudo nixos-rebuild switch
warning: Nix search path entry '/etc/nixos/configuration.nix' does not exist, ignoring
error: file 'nixos-config' was not found in the Nix search path (add it using $NIX_PATH or -I), at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/default.nix:1:60
(use '--show-trace' to show detailed location information)
building Nix...
warning: Nix search path entry '/etc/nixos/configuration.nix' does not exist, ignoring
error: file 'nixos-config' was not found in the Nix search path (add it using $NIX_PATH or -I), at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/default.nix:1:60
(use '--show-trace' to show detailed location information)
building the system configuration...
warning: Nix search path entry '/etc/nixos/configuration.nix' does not exist, ignoring
error: file 'nixos-config' was not found in the Nix search path (add it using $NIX_PATH or -I), at /nix/var/nix/profiles/per-user/root/channels/nixos/nixos/default.nix:1:60
(use '--show-trace' to show detailed location information)
The ~ after configuration.nix~ might be the problem here. How can I fix this?
Thanks!
Your Step 2 seems to have cause the issue here: The symlink should be called configuration.nix not configuration.nix~ as you have noticed.
You could fix this by running mv configuration.nix~ configuration.nix in the /etc/nixos folder which would rename configuration.nix~ to the correct configuration.nix.
No matter where the termial promt is in the filesystem, it suggests only executables from bin or sbin dir.
Take a look at this:
Last login: Sun Apr 26 15:24:57 on ttys004
You have mail.
box:~ mee$ A
AppleFileServer AssetCacheLocatorUtil AssetCacheManagerUtil AssetCacheTetheratorUtil
box:~ mee$ which AppleFileServer
/usr/sbin/AppleFileServer
box:~ mee$
Display all 2636 possibilities? (y or n)
box:~ mee$ cd ~/Desktop/wp-content/
box:wp-content mee$ ls
index.php languages plugins themes upgrade uploads
box:wp-content mee$
Display all 2636 possibilities? (y or n)
box:wp-content mee$ A
AppleFileServer AssetCacheLocatorUtil AssetCacheManagerUtil AssetCacheTetheratorUtil
Edit: I have created a new admin user to see if the problem persists, but the same error is there too.
That's as expected if you're completing the executable; completion follows the path. If you want completion in the local directory, you're likely going to have to type ./ before you hit the completion key, since frequently . is excluded from the path variable.
In this case, the completion is "smart" in that it is taking what it believes to be the context and using that to determine what you want. In this case, at the beginning of the line, it thinks you want to complete a command that can actually be executed, and thus it will only find things in the path.
I had I had a problem in starting the LaunchAgent and googled a lot and found multiple methods to troubleshoot, Noting them all down here in one place for the benefits of others
1) Ensure that after agents are copied in /Library/LaunchAgent folder reads as following.
-rw-r--r-- 1 root wheel 798 Jun 5 11:52 /Library/LaunchAgents/com.mycompany.myproduct.LaunchAgent.plist
(When you manually copy these files for debugging, you may have manually change these attributes using chown and chgroup commands).
2) Ensure that the path given in plist-> ProgramArguments is correct. (note that space is not required here)
3) Ensure that execution permission exists for file specified in "launchAgent plist->ProgramArguments"
4) check RunAtLoad attribute
5) Ensure that WatchPath file is present, please check if the the WatchPath need need any parameterization like /path/dir1/dir2/productname%BUILDNO%.trigger
6) if there is a file com.mycompanynewname.MyProductLaunchAgent.plist in the folder it may conflict with com.mycompanyoldname.MyProductLaunchAgent.plist
7) Look for /var/log/system.log for launchctl specific logs.
8) Read more about how LaunchDemon and LaunchAgent works and Apple documentation and http://www.launchd.info/
Bash-on-Ubuntu-on-Windows supports case-sensitive file paths. This means that I can create two files or directories with names only differing in capitalization. I have issues accessing those files, though.
Running
bash -c "touch Magic ; mkdir magic ; echo Secret! > magic/secret"
Creates a file names Magic, a directory named magic and a file names secret in that directory.
bash -c "ls -lR" yields
.:
total 0
drwxrwxrwx 2 root root 0 Aug 23 10:37 magic
-rwxrwxrwx 1 root root 0 Aug 23 10:37 Magic
./magic:
total 0
-rwxrwxrwx 1 root root 8 Aug 23 10:37 secret
(I am not sure why I get root, as it is not the default user, but that does not seem relevant to my question.)
Windows Explorer shows:
Now, while bash can easily access the magic/secret file in the directory, Windows seems to treat both the directory and the file as one and the same. So double-clicking the directory I get a "directory name invalid" error
Same goes for using cd, as I get The directory name is invalid. printed out.
Are there any APIs that allow me to access those case-sensitive paths, or create them? It seems that regular Windows APIs ignore character case completely when accessing existing files.
Case-sensitive paths can be used on Windows with NTFS, but it requires a bit of extra work.
First, case-sensitivity must be enabled system-wide. This is done by setting the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive registry value to 0, then restarting the system.
I found this part here.
Once case-sensitivity is enabled, it is possible to use CreateFile to with case-sensitive paths. To do that, you have to pass the FILE_FLAG_POSIX_SEMANTICS as part of the dwFlagsAndAttributes parameter. From msdn:
Access will occur according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support that naming.
I found this part in this answer.
By setting the registry setting and the CreateFile flag, I was able to access case-sensitive paths.
Since making a hash of a complete binary file would be far too heavy to compute in a reasonably fast time:
What are sufficient file information for hashing a file? The following lists what properties the resulting hashing should ideally have:
collision-free in respect to other files in the directory
fast
catch all file changes
As a rule of thumb, the less information we can use to create enough entropy, the better. Since the speed of retrieval for specific information may depend largely on the given environment (OS, file-IO of the language, IO of the used library, etc.), it should be disregarded here.
(This is my first attempt at a community wiki. My reason for making it one is that the information asked here is very generic but (hopefully) informative. I also would like this question to be marked as a community wiki, so it can be improved where fit. )
General Overview
Our goal here is to track as much differences between two file states while not using redundant data. Thus each informational source must be a disjointed subset of the information of the files state.
The following items represent sources of information about a file:
the name of the file
the directory-path relative to the specified document-root (aka absolute from document-root)
the files permissions
the files owner (user/group)
the last change time
the size of the file
the hostname of the machine the file resides on
the actual saved binary data
Per Item Considerations
Name of File
The name of the file is part of its absolute filesystem's path (the last bit) and as #La-comadreja said, it is unique in that no two files on a system can have the same absolute path. Using the File's name in combination with the rest of its absolute path (see directory-path for more information) is highly encouraged to avoid hash collisions with other files.
Directory-Path
While the files absolute path will be perfectly unique, it should be noted that in certain circumstances hashing the absolute path may be inappropriate. For instance, comparing the hashes of two files on different machines will most likely fail when both files do not have the identical absolute path on both machines. This becomes even more problematic on machines with different OS's and/or architectures. It is therefore encouraged to specify a document-root and resolve an absolute path from there.
Permissions
If you want to track changes to a files permissions, the tests below indicate that you would need to incoporate them into your hash directly as they do not change any other information about the file (most notably the timestamp). Note however that permissions are handled quite differently on different machines, so caution must be exercised here (for instance to use a canonical permission translation scheme).
Ownership
Ownership, just as permissions, is handled very differently across architectures and filesystems. A change of ownership does not change other information (as indicated by the tests below).
timestamp
The timestamp of a file is also something that is not unifiedly implemented across all (or at least the most common) systems. First of all, there are different timestamps on different filesystems we could be looking at: creation date, modified date, access date, etc. For our purpose the modified date is most suitable, as it is supported by most of the available filesystems [1] and holds the exact information we need: the last change to a file. However comparing files across different OS's may pose a problem, as Windows and Unix handle timestamps (in general) differently (see here [2] for a detailed article about the problem). Note that the modification date of a file changes whenever a file has been edited (disregarding edge cases), so timestamp indicates changes in file size (note that the opposite does not hold true, see file-size).
File size
The file size in bytes is an extremely good indication whether a file has been edited (except for permissions, ownership and name changes), as each edit would change the files content, thus changing its size. However this does not hold true if additions to a file are exactly as big as deletions. Thus the files timestamp may be a better indicator. Also, calculating a files binary size may be quite computation intensive.
Hostname
If one wants to compare files across multiple hosts and regard identical files on different hosts as different, then the hostname of the machine (or another suitable unique identifier for the host) should be included in the hash.
Binary Data
The binary data of the file has, of course, all necessary information to check if a file was changed. However, it is also too resource intensive to be of any practicability. It i highly discouraged to use this information.
Suggestions
The following sources should be used to compare files:
the name of the file
the directory path
the timestamp (see above for problems)
The following extra sources can be used to track more information:
permissions (see above)
ownership (see above)
hostname (when comparing across different machines)
The following sources of information should be disregarded:
file size
binary data
Tests
I did some tests on Debian checking whether changing one information would change another. Most interestingly rename, permission change, owner change did not affect a timestamp change or filesize change. (Note that these tests are currently only tested on Debian Linux. Other OS's will likely behave differently.)
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ mv baz baz2
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ chmod 777 foo
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ mv baz2 baz
$ echo "Another string" >> bar
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ sudo chown root baz
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 root alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
Assuming all the files are on the same machine, directory path and file name should produce a unique combination because two files in the same directory cannot have the same name. Directory path, filename and timestamp of last change should capture each change.
If the files are on different machines, the machine name should be included in the directory path.