I'm having trouble installing Homebrew, and it looks like the problem (invalid byte sequence in UTF-8 (ArgumentError) error message) is due to a fault in my PATH. when I run echo $PATH, I get the following (be sure to scroll to the far right in the code block below to see the fault):
/usr/local/mysql/bin:/opt/subversion/bin/:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:PATH=/usr/local/share/python:$PATH:PATH=/usr/local/share/npm/bin:$PATH:export PATH��:/usr/local/git/bin
I have no idea where those strange characters just before the /usr/local/git/bin path are coming from. I'm using bash (tried zshell, same problem). I can't find where this coming from. my .bash_profile file looks clean, too.
Examine your ~/.profile, ~/.bash_profile, and ~/.bashrc files. It is also possible that these values are being set in /etc/profile or other system-wide files, but the nature of the errors is such that I would assume they are the result of your own manual edits of your personal files. You're the best judge to decide what you may have changed and when.
Look for entries such as the following:
PATH='/usr/local/share/python:$PATH'
PATH='PATH=/usr/local/share/npm/bin:$PATH'
PATH='export PATH��:/usr/local/git/bin'
They should instead look like
PATH=/usr/local/share/python:$PATH
PATH=/usr/local/share/npm/bin:$PATH
PATH=$PATH:/usr/local/git/bin
# Not strictly necessary -- PATH is already exported
export PATH
See a pattern? These all add a value to PATH by setting it to prefix:$PATH or $PATH:suffix where the new prefix or suffix is the directory where you have installed a local package. Whether the new value should be a prefix or a suffix is probably of little consequence -- except if you are trying to override a system version (say, your /usr/local/git is installed because /usr/bin/git is too old -- then, it's important that your local version comes first in the PATH). There is also a minuscule speed difference the first time you run a command; the shell has to look in more places before finding it if it's at the end of the PATH.
The difference in quoting is significant -- PATH=$PATH:suffix expands to the old value of PATH with :suffix added on, whereas PATH='$PATH:suffix' replaces the old value of PATH with the literal string $PATH with :suffix added on. You're lucky none of this has ended up replacing your original PATH completely, which would render your shell by and large inoperable (at least until you discover that you have to use /bin/ls instead of just ls).
Related
I am pretty new to the Mac environment so I have lots of gaps knowledge-wise. I need to edit the order of the PATH variables that my system uses. I have a .zshrc file in my home directory which has the following contents as of now:
export PATH="$PATH:/Users/mehmetsanisoglu/Desktop/Programs/flutter/bin"
export PATH="$PATH:/Users/mehmetsanisoglu/.rbenv/shims"
that's all, just these two lines. But when I type echo $PATH I get:
/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin:/Applications/Postgres.app/Contents/Versions/latest/bin:/Users/mehmetsanisoglu/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/mehmetsanisoglu/Desktop/Programs/flutter/bin:/Users/mehmetsanisoglu/.rbenv/shims
I am guessing the .zshrc file I have crated appends the items I have in there to the actual list of PATH elements. My question is, how do I get there and edit the ordering of these elements, because I need the ".rbenv" to come before "/usr/bin". Thanks
zsh has a special array variable path that's linked to PATH - changing one changes the other. Treating the path as an array of directories is often much handier than treating it as a string of colon-separated directories.
You can append to it with
path+=(/some/path)
# or
path+=(/some/path/1 some/path/2)
and prepend to it with
path[1,0]=/some/path
# or
path[1,0]=(/some/path/1 /some/path2)
I able to load libpcap.dylib which is confusing cause I can't figure out the actual file location. Doing find / -name libpcap.A.dylib or libpcap.dylib says no such file.
Also finder search with libpcap just results in libpcap.A.tbd and libpcap.rb.
libpcap.A.tbd shows "Install location /usr/lib/libpcap.A.dylib", but it does not actually exist there.
I wanted to locate the actual dylib file cause I running into issue with being able to import function, So I wanted to check file to make sure I have function names correct.
So I wanted to check file to make sure I have function names correct.
The first thing to check is the pcap man page - from the command line, it'd be
man pcap
It's a bit long, but it should mention all the functions available in libpcap; it may be easier than
nm /usr/lib/libpcap.dylib | egrep ' T '
(and doesn't require you to remember that the leading underscores in the output of that command are NOT part of the name of the function, they're a leftover from ancient UNIX history).
Where is libpcap.dylib?
/usr/lib/libpcap.A.dylib. /usr/lib/libpcap.dylib is a symbolic link to it.
CLISP's interface to PARI is configured with the configure.in containing AC_LIB_LINKFLAGS([pari]) from lib-link.m4.
The build process also requires the Makefile to know where the datadir of PARI is located. To this end, Makefile.in has
prefix = #LIBPARI_PREFIX#
DATADIR = #datadir#
and expects to find $(DATADIR)/pari/pari.desc (normally
/usr/share/pari/pari.desc or /usr/local/share/pari/pari.desc).
This seems to work on Mac OS X where PARI is installed by homebrew in /usr/local (and LIBPARI_PREFIX=/usr/local), but not on Ubuntu, where PARI is in /usr, and LIBPARI_PREFIX is empty.
How do I insert the location of the PARI's datadir into the Makefile?
PS. I also asked this on the autoconf mailing list.
PPS. In response to #BrunoHaible's suggestion, here is the meager attempt at debugging on Linux (where LIBPARI_PREFIX is empty).
$ bash -x configure 2>&1 | grep found_dir
+ found_dir=
+ eval ac_val=$found_dir
+ eval ac_val=$found_dir
You are trying to use $(prefix) in an unintended way. In an Autotools-based build system, the $(prefix) represents a prefix to the target installation location of the software you're building. By setting it in your Makefile.in, you are overriding the prefix that configure will try to assign. However, since you appear not to have any installation targets anyway, at least at that level, that's probably more an issue of poor form than a cause for malfunction.
How do I insert the location of the PARI's datadir into the Makefile?
I'd recommend computing or discovering the needed directory in your configure script, and exporting it to the generated Makefile via its own output variable. Let's take the second part first, since it's simple. In configure.in, having in some manner located the wanted data directory and assigned it to a variable
DATADIR=...
, you would make an output variable of that via the AC_SUBST macro:
AC_SUBST([DATADIR])
Since you are using only Autoconf, not Automake, you would then manually receive that into your Makefile by changing the assignment in your Makefile.in:
DATDIR = #DATADIR#
Now, as for locating the data directory in the first place, you have to know what you're trying to implement before you can implement it. From your question and followup comments, it seems to me that you want this:
Use a data directory explicitly specified by the user if there is one. Otherwise,
look for a data directory relative to the location of the shared library. If it's not found there then
(optional) look under the prefix specified to configure, or specifically in the specified datadir (both of which may come from the top-level configure). Finally, if it still has not been found then
look in some standard locations.
To create a configure option by which the user can specify a custom data directory, you would probably use the AC_ARG_WITH macro, maybe like this:
AC_ARG_WITH([pari-datadir], [AS_HELP_STRING([--with-pari-datadir],
[explicitly specifies the PARI data directory])],
[], [with_pari_datadir=''])
Thanks to #BrunoHaible, we see that although the Gnulib manual does not document it, the macro's internal documentation specifies that if AC_LIB_LINKFLAGS locates libpari then it will set LIBPARI_PREFIX to the library directory prefix. You find that that does work when the --with-libpari option is used to give it an alternative location to search, so I suggest working with that. You certainly can try to debug AC_LIB_LINKFLAGS to make it set LIBPARI_PREFIX in all cases in which the lib is found, but if you don't want to go to that effort then you can work around it (see below).
Although the default or specified installation prefix is accessible in configure as $prefix, I would suggest instead going to the specified $datadir. That is slightly tricky, however, because by default it refers to the prefix indirectly. Thus, you might do this:
eval "datadir_expanded=${datadir}"
Finally, you might hardcode a set of prefixes such as /usr and /usr/local.
Following on from all the foregoing, then, your configure.in might do something like this:
DATADIR=
for d in \
${with_pari_datadir} \
${LIBPARI_PREFIX:+${LIBPARI_PREFIX}/share/pari} \
${datadir_expanded}/pari \
/usr/local/share/pari \
/usr/share/pari
do
AS_IF([test -r "$[]d/pari.desc"], [DATADIR="$[]d"; break])
done
AS_IF([test x = "x$DATADIR"], [AC_MSG_ERROR(["Could not identify PARI data directory"])])
AC_SUBST([DATADIR])
Instead of guessing the location of datadir, why don't you ask PARI/GP where its datadir is located? Namely,
$ echo "default(datadir)" | gp -qf
"/usr/share/pari"
does the trick.
How do . and .., as paths (vs. ranges, e.g., {1..10}, which I'm not concerned with), really work? I know what they do, and use them all the time, but don't fully grasp how/where they're interpreted. Does the shell handle them? The interpreting process? The OS?
The reason why I'm asking is that I'd like to be able to use ... to refer to ../.., .... to refer to ../../.., etc. (up to some small finite number; I don't need bash to process an arbitrarily large number of dots). I.e., if my current directory is /tmp/let/me/out, and I call cd ..., my resulting current directory should be /tmp/let. I don't particularly care if ... etc. show up in ls -a output like . and .. do, but I would like to be able to call cat /tmp/let/me/out/..../phew.txt to print the contents of /tmp/phew.txt.
Pointers to relevant documentation appreciated as well as direct answers. This kind of syntax question is very hard to Google.
I'm using bash 4.3.42, by the way, with the autocd and globstar shell options.
. and .. are genuine directory names. They are not "sort-cuts", aliases, or anything fake.
They happen to point to the same inode as the other name you use. A file or directory can have several names pointing to the same inode, these are usually known as hard links, to distinguish them from symbolic (or soft) links.
If you are on Linux or OS X you can use stat to look at most of the inode metadata - it is what ls looks at. You will see there is an inode number. If you stat . and stat current-directory-name you will see that number is the same.
The one thing that is not held in the inode is the filename - that is held in the directory.
So . and .. reside in the directory on the file system, they are not a figment of the shell's imagination. So, for example, I can use . and .. quite happily from C.
I doubt you can change them - personally I have never tried and I never will. You would have to change what these filenames linked to by editing the directory. If you managed it you would probably do irreparable damage to your file system.
I write this to clarify what has already been written before.
In many file systems a DIRECTORY is a file; a special type of file that the file system identifies as being distinctly a directly.
A directory file contains a list of names that map to files on the disk
A file, including a directly does not have an intrinsic name associated with it (not true in all file systems). The name of a file exists only in a directory.
The same file can have an entry in multiple directories (hard link). The same file can then have multiple names and multiple paths.
The file system maintains in every directory entries for "." and ".."
In such file systems there are always directory ENTRIES for the NAMES "." and "..". These entries are maintained by the file system.
The name "." links to its own directory.
The name ".." links to the parent directory EXCEPT for the top level directory where it links to itself (. and .. thus link to the same directory file).
So when you use "." and ".." as in /dir1/dir2/../dir3/./dir4/whatever,
"." and ".." are processed in the exact same way as "dir1" and "dir2".
This translation is done by the file system; not the shell.
cd ...
Does not work because there is no entry for "..." (at least not normally).
You can create a directory called "..." if you want.
You can actually achieve something like this, though this is an ugly hack:
You can run a command before every command entered to bash, and after every command. For that you trap the DEBUG pseudo signal and set a command to PROMPT_COMMAND, respectively.
trap 'ln -s ../.. ... &>/dev/null | true' DEBUG
PROMPT_COMMAND='rm ...'
With this, it seems like there's an additional entry in the current directory:
pwd
# /tmp/crazy-stuff
ls -a
# . .. ... foo
ls -a .../tmp/crazy-stuff
# . .. ... foo
Though this only works in the current directory, because the symbolic links is deleted after each command invokation. Thus ls foo/bar/... won't work this way.
Another ugly hack would be to "override" mkdir such that it populates every new directory with these symbolic links.
See also the comments on the second answer here, particularly Eliah's: https://askubuntu.com/questions/327126/what-is-a-dot-only-named-folder
Much in the same way that when you cd into some directory subdir, you're actually following a pointer that points to that directory, .. is a pointer added by the OS that points to the parent directory, and I'd imagine . works the same way.
I have created a project in /Projects/test that have the following files:
/Projects/test/first.rb
/Projects/test/second.rb
In first.rb, I do:
load 'second.rb'
And it gets loaded correctly. However, if I open the console and I type $:, I don't see the current directory "." in the load path. How does Ruby know where to load that 'second.rb' from?
See the documentation of Kernel#load clearly :
Loads and executes the Ruby program in the file filename. If the filename does not resolve to an absolute path, the file is searched for in the library directories listed in $:. If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. In no circumstance will any local variables in the loaded file be propagated to the loading environment.
In case load 'second.rb' - second.rb has been internally resolved to the absolute path /Projects/test/second.rb,as your requiring file in the directory is same as required file directory. Nothing has been searched to the directories listed in$: for your case.
Just remember another way always
- The load method looks first in the current directory for files
Contrary to the currently accepted answer, the argument 'second.rb' does not resolve to an absolute path. If that were what was meant, you would also be able to require 'second.rb', since require has exactly the same wording about absolute paths.
I think what's happening here is just that the phrasing in the documentation for load is not clear at all about what the actual steps are. When it says "Loads and executes the Ruby program in the file filename," it means that literally — it treats the argument as a file name and attempts to load it as a Ruby program. If isn't an absolute path†, then Ruby goes through $LOAD_PATH and looks for it in those places. If that doesn't turn anything up, then it just goes ahead and tries to open it just as you passed it in. That's the logic that MRI actually follows.
† The actual check that Ruby does is essentially "Does the path start with '/', '~' or './'?".