Does not work on Mac

[KurtPfeifle]

From "pitch":

" Written in Bash, the framework has been tested under Linux distributions, partially tested under Cygwin, and should work under BSD/Mac"

However,

kp@mbp:git.ubiquitous_bash>  . ./ubiquitous_bash.sh 
   -bash: realpath: command not found

kp@mbp:git.ubiquitous_bash>  sudo port install realpath
   --->  Fetching archive for realpath
   --->  Attempting to fetch realpath-1.0.1_0.darwin_16.x86_64.tbz2 from https://packages.macports.org/realpath
   --->  Attempting to fetch realpath-1.0.1_0.darwin_16.x86_64.tbz2 from http://nue.de.packages.macports.org/realpath
   --->  Attempting to fetch realpath-1.0.1_0.darwin_16.x86_64.tbz2 from http://lil.fr.packages.macports.org/realpath
   --->  Fetching distfiles for realpath
   --->  Verifying checksums for realpath
   --->  Extracting realpath
   --->  Configuring realpath
   --->  Building realpath
   --->  Staging realpath into destroot
   --->  Installing realpath @1.0.1_0
   --->  Activating realpath @1.0.1_0
   --->  Cleaning realpath
   --->  Updating database of binaries
   --->  Scanning binaries for linking errors
   --->  No broken files found.                             

kp@mbp:git.ubiquitous_bash>  . ./ubiquitous_bash.sh 
   realpath: illegal option -- L
   Usage: realpath [-q] [path ...]
          realpath -h
          realpath -v

[mirage335]

Extremely interesting and quite surprising, thank you for the bug report!

Are other versions of realpath available under Mac which supports "-L" as under Linux? Perhaps a specific test or alias for these could be added. http://man7.org/linux/man-pages/man1/realpath.1.html

Temporarily, extra tests have been added to abort script operation earlier if realpath, among other things, is not found to provide the needed functionality.

https://github.com/mirage335/ubiquitous_bash/commit/1c0651211307b736c309de67b247a77523cfb95f

Please report back with any more information you can find regarding this differing realpath behavior. Fixing this is a high priority, and ubiquitous bash is considered not working under Mac until this is resolved.

[KurtPfeifle]

I don't use brew, so I cannot tell if any realpath would be available from there which supports "-L".

I only shortly checked if something like readlink -f could serve as a replacement alias, but then I discovered that macOS' readlink does not support "-f".... 👎

Maybe the plain macOS realpath already gives the results you need? If you point me to a list of these corner cases you want to get covered, I can test them and report back.

[mirage335]

Unfortunately, identifying those corner cases is one of, if not the, most difficult problem to solve that could have arisen, anywhere near such critical functionality. Absolute path functions were written more than five years ago, and are required to produce certain exact results with such inputs as "/home/user/../user/folder/linkedfolder/../script.sh", where "linkedfolder" might be a symlink to "folder". Most critically, these absolute paths are used as part of the safety checks done by _safeRMR .

A man page for the version of readlink you have on your Mac would be helpful. A statically compiled version of a Mac compatible readlink binary supporting "-L" might also be helpful - this might work out of the box if placed in "_bin" within this repository, as ubiquitous bash appends that to PATH.

Long term, the best solution might be to include all possible symlink and ".." issues with file paths as built-in tests for the absolute path functions. I will set about doing that.

Thanks again for reporting this.

[KurtPfeifle]

That manpage is rather "thin", as the screenshot below shows:

---

[mirage335]

Indeed. Looks like not a lot of functionality there. Both "-L" and "-s" are missing, as well as "--relative-to". At the very least, it might be difficult to make the "_localDir" function work with this version of realpath.

Apparently, the coreutils version of realpath is available for Mac through Brew. This could be noted in the documentation for ubiquitous bash, but if a statically compiled binary can be included, that would probably be better. https://stackoverflow.com/questions/3572030/bash-script-absolute-path-with-osx

[KurtPfeifle]

You mentioning coreutils gave me the idea to look further. I had it even installed, but it was not on my $PATH.

Here is the output of the --help:

kp@mbp:folder>  LANG=C /opt/local/libexec/gnubin/realpath --help
Usage: /opt/local/libexec/gnubin/realpath [OPTION]... FILE...
Print the resolved absolute file name;
all but the last component must exist

  -e, --canonicalize-existing  all components of the path must exist
  -m, --canonicalize-missing   no path components need exist or be a directory
  -L, --logical                resolve '..' components before symlinks
  -P, --physical               resolve symlinks as encountered (default)
  -q, --quiet                  suppress most error messages
      --relative-to=DIR        print the resolved path relative to DIR
      --relative-base=DIR      print absolute paths unless paths below DIR
  -s, --strip, --no-symlinks   don't expand symlinks
  -z, --zero                   end each output line with NUL, not newline

      --help     display this help and exit
      --version  output version information and exit

GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Report realpath translation bugs to <http://translationproject.org/team/>
Full documentation at: <http://www.gnu.org/software/coreutils/realpath>
or available locally via: info '(coreutils) realpath invocation'

---

I'll test ubiquitous_bash with that included in PATH later, and report back.

[mirage335]

Thanks!

Please consider pulling the latest version of ubiquitous_bash first. There are some added safety checks to ensure safeRMR aborts in case of insufficient realpath functionality.

[mirage335]

By the way, if you can identify the path to which the coreutils version of realpath is usually installed, an automatic detect-and-alias procedure can be added. Something like the output of "which realpath" would be helpful.

[mirage335]

Has any further progress been made on this?

[KurtPfeifle]

Sorry for the delay, I got side-tracked -- thanks for asking and poking some more.

Here is how the MacPorts coreutils package installs its version of "realpath":

$>  port contents coreutils | grep realpath
  /opt/local/bin/grealpath
  /opt/local/libexec/gnubin/man/man1/realpath.1.gz
  /opt/local/libexec/gnubin/realpath
  /opt/local/share/man/man1/grealpath.1.gz

All the tools in /opt/local/libexec/gnubin/ carry the original names and are the real binaries. What names start with a g (like 'grealpath') and are in /opt/local/bin/ are only symlinks to the real binaries in /opt/local/libexec/gnubin/. Similar is true for manpages and $MANPATH.

As by default, only /opt/local/bin/ is part of $PATH, but not /opt/local/libexec/gnubin/, you'd have to be aware that you have to

• either tweak your $PATH to include /opt/local/libexec/gnubin/ (then original util-name can be used),
• or call the GNU version of any fooutil by its symlink gfooutil (with the letter g prefixed).

$>  ls -l $(port contents coreutils|grep realpath)
  -rwxr-xr-x  1 root  admin  65544 Dec 26 23:14 /opt/local/bin/grealpath
  lrwxr-xr-x  1 root  admin     40 Dec 26 23:14 /opt/local/libexec/gnubin/man/man1/realpath.1.gz -> /opt/local/share/man/man1/grealpath.1.gz
  lrwxr-xr-x  1 root  admin     24 Dec 26 23:14 /opt/local/libexec/gnubin/realpath -> /opt/local/bin/grealpath
  -r--r--r--  1 root  admin    977 Dec 26 23:14 /opt/local/share/man/man1/grealpath.1.gz

[mirage335]

Much thanks! I will add support for this ASAP.

[mirage335]

Sorry, looks like this will have to wait until I get back from CES. However, I will see to it this gets integrated then, as part of general support for different binary locations on other platforms.

[mirage335]

Sorry this has taken so long. Events after CES unavoidably put me behind several weeks. This is still an important issue, and I will be adding a fix ASAP.

[mirage335]

Hi, hope you are still with me. I know it has been a while.

Have to be honest, Linux support is getting prioritized over Mac and MSW. The primary goal of Ubiquitous Bash is to create stable interfaces between external programs, and developers who really need this capability are best served by the openness Linux provides.

A fix will still be added, but I will probably not get around to it until after addressing similar issues detecting external programs under the MSW platform as well.

[mirage335]

Well, looks like this may need to be fixed sooner rather than later after all.

The programs named by "_getAbsolute_criticalDep" uniquely are required for safe script operation while not being resources that would necessarily be available on UNIX systems. Consequently, it may be better to implement equivalent bash functions, with alternatives and test procedures.

[mirage335]

Please retest with this command.

./ubiquitous_bash.sh _getScriptAbsoluteLocation

Coreutils version of realpath should be automatically detected, or if not, readlink should be used as a fallback.

[mirage335]

This is still awaiting retesting on the BSD/Mac platform. Additionally, I would like to have help adding "_getDep" related procedures to automatically install, or at least recommend, installation and detection of suitable binaries such as Coreutils.