When I try to set a relative code path in a escript with -pz like this
#!/usr/bin/env escript
%% -*- erlang -*-
%%! -pz ../dir-of-some-beams
The path is interpreted relative to the directory from where I run the escript from, which renders it useless for setting the path relative to the script location.
My current "workaround" is using a absolute path which is annoying since all this is part of a repository and I don't want it to be location dependent.
So how can I set the code path relative to the directory the escript is located in?
Just found it out myself:
At the beginning of main add code like this:
true = code:add_pathz(filename:dirname(escript:script_name())
++ "/../dir-of-some-beams"),
I recommend always testing for true whith these code functions, because its easy to type code:add_pathsz which wants a list of strings and always returns ok, even if you pass it just a string -- but it doesn't set the code path to the single directory (which is pretty annoying behaviour btw).
Related
How can I retrieve the path to the go binary in a container that does not have which programatically?
One option would be to execute which go as follows:
bytes, err := exec.Command("which", "go").Output()
However, I would like to not depend on which being available. Does go provide any in-built mechanism to retrieve this and if not, what is the alternative apart from having the user pass in the path themselves?
From the man page of which:
Which takes one or more arguments. For each of its arguments it prints to stdout the full path of the executables that would have been executed when this argument had been entered at the shell prompt. It does this by searching for an executable or script in the directories listed in the environment variable PATH using the same algorithm as bash(1).
Go's os/exec.LookPath function is very close to this functionality:
LookPath searches for an executable named file in the directories named by the PATH environment variable. If file contains a slash, it is tried directly and the PATH is not consulted. The result may be an absolute path or a path relative to the current directory.
Use path/filepath.Abs if you need a guaranteed absolute path.
I don't expect this to be the best answer, but it is one that I just found. I was hoping for more of a go-specific one, but in the meantime type in linux is a default built-in one available in bash and sh (alpine).
You can test this yourself by running type type which yields:
type is a shell builtin
The usage in go would look like this:
b, err := exec.Command("type", "go").Output()
if err != nil {
/* 'type' is not available on the O/S */
}
goPath := strings.TrimPrefix(strings.TrimSuffix(string(b), "\n"), "go is ")
The reason the Trim functions are required is because the output would look like this:
go is /usr/local/go/bin/go\n
This isn't the nicest way of going about it, but it works.
I am trying to get a value of the full current directory path from within .bzl rule. I have tried following:
ctx.host_configuration.default_shell_env.PATH returns "/Users/[user_name]/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:...
ctx.bin_dir.path returns bazel-out/local-fastbuild/bin
pwd = ctx.expand_make_variables("cmd", "$$PWD", {}) returns string $PWD - I don't think this rule is helpful for me, but may be just using it wrong.
What I need is the directory under which the cmd that runs Bazel .bzl rule is running. For example: /Users/[user_name]/git/workspace/path/to/bazel/rule.bzl or at least first part of the path prior to the WORKSPACE directory.
I can't use pwd because I need this value before I call ctx.actions.run_shell()
Are there no attributes in Bazel configurations that hold this value?
The goal is to have hermetic builds, so you shouldn't depend on the absolute path.
Feel free to use pwd inside the command of ctx.actions.run_shell() (for reproducible builds, be careful, avoid putting the absolute path in the generated files).
Edit.
Technically, there are some workarounds. For example, you can pass the path via the --define flag:
bazel build :all --define=path=$(pwd)
Then the value will be available using ctx.var["path"].
Based on your comment below, you want the path to declare an output. Let me repeat: You shouldn't use an absolute path to declare the output file. Declare an output in your package. Then ask the tool you call to use that output.
For example, when you call gcc, you can use -o to specify the output. When a tool writes to stdout, use the shell to redirect it. If the tool is really not flexible, you may want to wrap it with your own script (e.g. call the tool and copy the output file).
Using an absolute path here is not the right solution. For example, it should be possible to execute the action on a remote machine (where your absolute path won't make sense.
Zip may be a reasonable solution. It's useful when you cannot know in advance the number or the names of the output files.
I'm trying to repackage into a Docker container some Lua library that is made of the main module and some helper modules. The helper modules are kept inside a subfolder of the library so that imports from the main file are done as
require 'helpers/SomeHelper'
The problem is: because of the way I want the Docker container to work, it would be extremely helpful if I can invoke this library from a different working folder. That is, my call to the main program would be something like
th /app/main.lua
regardless of the actual working directory I'm standing. Unfortunately, relative imports seem to fail when the working directory is different from the directory where the main file is located.
Is there any way I can configure LUA_PATH or any other mechanism to make these imports work correctly? Note that changing the code of the library itself would be a poor solution, as it wasn't developed by me and I would like to be able to update it to newer versions easily.
If you don't care about the working directory, you can just load lfs / LuaFileSytem and use lfs.chdir( src_dir ) to change to the source directory (potentially saving the current working directory with lfs.currentdir( ) first.)
You can also extend the search path of Lua so that it will search those extra directories. The search is driven by package.searchpath. To add a directory /foo/bar/ to the search in a way that supports all normally supported library layouts, add
/foo/bar/?.lua;/foo/bar/?/init.lua to package.path
/foo/bar/?.so (or .dylib or .dll on other OSen) to package.cpath
You can use several ways to extend the path.
One option that works well is to set the LUA_PATH / LUA_CPATH environment variables. (A ;; sequence in one of them will expand to the full default path.) This can be done from .profile or other setup scripts via an earlier export LUA_PATH="..." or (if started from a wrapper script) inline by setting variables just for that call LUA_PATH="..." lua /foo/bar.lua. (Note that if you export this variable in too broad a scope, other Lua scripts will also get their path extended and may find potentially incompatible Lua libraries.)
(You can also manually modify package.(c)path from LUA_INIT. That way, you won't be able to independently disable LUA_INIT or LUA_PATH, but you can use all of Lua to generate the path dynamically.)
A third option (this may be best in your specific case) is to put the extension of package.path at the top of your main script, as in
do
local dir = (arg[0]:match "^(.*)/$")
if dir then -- else cwd is . which works by default
package.path = dir.."/?.lua;"..dir.."/?/init.lua;"..package.path
package.cpath = dir.."/?.so;"..package.cpath
end
end
-- rest of your program goes here
When running a script with the Lua interpreter, arg[0] is the script. So this extends the path to include the program's directory no matter where it is located, and it will only affect the search path of this particular script / program.
You should not forget about that not all modules are loaded from FS directly.
E.g. to improve perfomance it is possible read/compile file to memory and then
use preload table to provide way to load module from memory.
Basic example
--- preload code. It can be done by host application.
local FooUtils = function()
return {
print = function(...)
print("foo", ...)
end
}
end
local Foo = function()
local Utils = require "foo.utils"
return {
foo = function()
Utils.print"hello"
end
}
end
package.preload['foo.utils'] = FooUtils
package.preload['foo'] = Foo
--- main application
require "foo".foo()
In this example assume that FooUtils and Foo just example of compiled modules.
E.g. it can be like FooUtils = loadstring('path/to/utils.lua) and it can be done
even in separate Lua state and then used in any other.
It is important to remember that Foo module have no idea about how host application does lookup of foo.utils.
So there no standart way to provide original file path or relevant paths.
So if you write some module wich relays on relative paths then this module
may be not working in some environments.
So I just suggest use full namespace like require 'foo.utils' instead of require 'utils'
I make a call just like this:
value = ./simulated_annealing
Which is a C Object file, but Rails tells me it cannot find that file. I
put it in the same dir that the rest of the models files (since it's
called by one of those models), but I guess it should be in any other
place.
I've tried that outside Ruby and it works great.
What do I have to do?
The thing is, when you say:
./simulated_annealing
you're explicitly saying: run file named simulated_annealing which is found in the current directory. That's what the ./ means. If the file's located elsewhere you need to provide the path to it, or add that path to the environment variable $PATH. So, you should replace that line with:
/path/to/simulated_annealing
where /path/to represents the actual path.
The best option is to use an absolute path for running the program. For ex.,
you can create a directory "bin" under your rails application top level
directory. Place your program under "bin" directory. Then you can
execute the program something like:
cmd = "#{RAILS_ROOT}/bin/cbin arg1 arg2"
value = `#{cmd}`
In my controller, a function runs a shell command. I'm having a hard time to locate the script in the commad. For example, in my controller I have this:
def find_usage
command = 'ruby usage.rb'
#{command}
end
My question is where to put that usage.rb file and how to reference it without hard code the entire path. It works when I hard code the path as /home/user/xyz/usage.rb, but I don't think it's right to do.
You could stuff it into /script and then reference RAILS_ROOT/script/usage.rb in your code. RAILS_ROOT is a constant that contains the absolute path to your application.