I have a program in which I use a lot "../" which is to go one level up
in the file system and run some process on the directory with specific name. I have a command line tool in Go.
I have 3 questions
there is nicer way to do it instead of “../“
is there a const with which I can use instead of “/“
if 2 is not available should I create “constants“ under that internal package to share the “/“ between packages since I need it in
many place (from diff packages...)
example
dir.zip("../"+tmpDirName, "../"+m.Id+".zip", "../"+tmpDirName)
Set a variable, and use that everywhere:
path := "../"
or
path := ".." + string(os.PathSeparator)
then later:
dir.zip(path+tmpDirName, path+m.Id+".zip", path+tmpDirName)
This makes it very easy to change the path in the future, via a command line option, configuration, or just editing the value.
Yes. os.PathSeparator is the OS-specific path separator for the current architecture.
n/a
declare a global const somewhere, but I would just use ".." everywhere
os.PathSeparator
use filepath.Join("..", someDir, someFilename)
Related
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.
I'm using Lua in interactive mode on a Mac (thanks to rudix.org).
When I want to load a file I do:
dofile("/my/long/path/to/my/directory/file.lua")
I want to do a different thing, that is:
put all my files in a desktop directory myDirectory;
then call the file from the terminal this way dofile("file.lua");
Is this possible? How?
If the path is fixed, you can just redefine dofile:
local _dofile=dofile
local path=("/my/long/path/to/my/directory/")
function dofile(x)
return _dofile(path..x)
end
You may put this (and other initializations) in a file and set the environment variable LUA_INIT to its location. After this, every invocation of lua will see the version of dofile redefined above and the users will be able to say simply dofile("foo.lua").
Alternatively, you can use require, which looks for modules in a list of paths in package.path or LUA_PATH.
I have a project that contains a folder to manage file templates, but it doesn't look like Go provides any support for non-Go-code project files. The project itself compiles to an executable, but it needs to know where this template folder is in order to operate correctly. Right now I do a search for $GOPATH/src/<templates>/templates, but this feels like kind of a hack to me because it would break if I decided to rename the package or host it somewhere else.
I've done some searching and it looks like a number of people are interested in being able to "compile" the asset files by embedding them in the final binary, but I'm not sure how I feel about this approach.
Any ideas?
Either pick a path (or a list of paths) that users are expected to put the supporting data in (/usr/local/share/myapp, ...) or just compile it into the binary.
It depends on how you are planning to distribute the program. As a package? With an installer?
Most of my programs I enjoy just having a single file to deploy and I just have a few templates to include, so I do that.
I have an example using go-bindata where I build the html template with a Makefile, but if I build with the 'devel' flag it will read the file at runtime instead to make development easier.
I can think of two options, use a cwd flag, or infer from cwd and arg 0:
-cwd path/to/assets
path/to/exe -cwd=$(path/to/exe/assets)
Internally, the exectable would chdir to wherever cwd points to, and then it can use relative paths throughout the application. This has the added benefit that the user can change the assets without having to recompile the program.
I do this for config files. Basically the order goes:
process cmd arguments, looking for a -cwd variable (it defaults to empty)
chdir to -cwd
parse config file
reparse cmd arguments, overwriting the settings in the config file
I'm not sure how many arguments your app has, but I've found this to be very useful, especially since Go doesn't have a standard packaging tool that will compile these assets in.
infer from arg 0
Another option is to use the first argument and get the path to the executable. Something like this:
here := path.Dir(os.Args[0])
if !path.IsAbs(os.Args[0]) {
here = path.Join(os.Getwd(), here)
}
This will get you the path to where the executable is. If you're guaranteed the user won't move this without moving the rest of your assets, you can use this, but I find it much more flexible to use the above -cwd idea, because then the user can place the executable anywhere on their system and just point it to the assets.
The best option would probably be a mixture of the two. If the user doesn't supply a -cwd flag, they probably haven't moved anything, so infer from arg 0 and the cwd. The cwd flag overrides this.
So currently I have included the following in my .bashrc file.
export RUBYLIB=/home/git/project/app/helpers
I am trying to run rspec with a spec that has
require 'output_helper'
This file is in the helpers directory. My question is that when I change the export line to:
export RUBYLIB=/home/git/project/
It no longer finds the helper file. I thought that ruby should search the entire path I supply, and not just the outermost directory supplied? Is this the correct way to think about it? And if not, how can I make it so RUBY will search through all subdirectories and their subdirectories, etc?
Thanks,
Robin
Similar to PATH, you need to explicitly name the directory under which to look for libraries. However, this will not include any child directories within, so you will need to list any child sub-directories as well, delimiting them with a colon.
For example:
export RUBYLIB=/home/git/project:/home/git/project/app/helpers
As buruzaemon mentions, Ruby does not search subdirectories, so you need to include all the directories you want in your search path. However, what you probably want to do is:
require 'app/helpers/output_helper'
This way you aren't depending on the RUBYLIB environment variable being set a certain way. When you're deploying code to production, or collaborating with others, these little dependencies can make for annoying debugging sessions.
Also as a side note, you can specify . as a search path, rather than using machine-specific absolute paths.
I'm trying to create a Makefile that uses information from the path to create a relevant rpm name. Suppose I have two different possible paths:
PATH1 = /usr/local/home/jsmith/code/main
PATH2 = /usr/local/home/jsmith/code/dev/ver2
If "main" is detected in the path, I want to detect and append "main" to the rpm name. If "dev" is detected in the path, I want to detect and append "ver2" to the rpm name.
I'm new to shell scripting and really don't have a good idea on where to start. I could easily do this in something like python, but its for a Makefile so I need to do it in shell.
"main" in the path would be constant, but if "main" doesn't exist, the dev path name would need to be extracted. Here's a few mow examples:
/usr/local/home/jsmith/code/main
/usr/local/home/jsmith/code/dev/ver_usa
/usr/local/home/jsmith/code/dev/ver_mexico
/usr/local/home/jsmith/code/dev/ver3
If "dev" existed, it would be needed to extract "ver_usa", "ver_mexico", "ver3", etc. The dir name needing to be extracted would exactly follow "dev".
something like this, assuming "main" and "ver2" are not constant
some_rpm_name="some rpm"
PATH=/usr/local/home/jsmith/code/main
#PATH2=/usr/local/home/jsmith/code/dev/ver2
s=${PATH##*/}
case "$s" in
*main ) RPM_NAME="${some_rpm_name}_main";;
*ver2) RPM_NAME="${some_rpm_name}_ver2";;
esac
echo $RPM_NAME
Use grep and check for return value?
Also, you can run python in Makefile.
It looks like the last element of the path is always the one you want.
rpmname=$rpmname+${pathname##*/}
or
rpmname=$rpmname+$(basename pathname)