I have a file main.lua:
require("hello")
and a file hello.lua in the directory foo bar! baz (with !) in it:
module(...,package.seeall)
print("hello from hello.lua")
when I set (on Windows) the environment variable LUA_PATH to the directory:
set LUA_PATH="C:\Programme\Lua\5.1\foo bar! baz\?.lua"
I get a strange error:
C:\Programme\Lua\5.1>lua main.lua
lua: main.lua:4: module 'hello' not found:
no field package.preload['hello']
no file '"C:\Programme\Lua\5.1\foo barC:\Programme\Lua\5.1 baz\hello.lua
"'
no file '.\hello.dll'
no file '.\hello51.dll'
no file 'C:\Programme\Lua\5.1\hello.dll'
no file 'C:\Programme\Lua\5.1\hello51.dll'
no file 'C:\Programme\Lua\5.1\clibs\hello.dll'
no file 'C:\Programme\Lua\5.1\clibs\hello51.dll'
no file 'C:\Programme\Lua\5.1\loadall.dll'
no file 'C:\Programme\Lua\5.1\clibs\loadall.dll'
stack traceback:
[C]: in function 'require'
main.lua:4: in main chunk
[C]: ?
See the very strange path C:\Programme\Lua\5.1\foo barC:\Programme\Lua\5.1 baz\hello.lua? What is so special about the exclamation mark (bang)? How to get that right in windows? On Mac this seems to be working fine.
"This substitution only happens the first time Lua sets the path
(either from LUA_PATH or from the default from luaconf). If you
set the path by other means, you can avoid the problem."
More info and potential alternatives: http://lua-users.org/lists/lua-l/2012-08/msg00052.html
The explanation is correct (it's documented behavior on Windows), but I can also offer a possible solution (or rather a workaround): since only the first exclamation mark is going to be replaced, instead of using set LUA_PATH="C:\Programme\Lua\5.1\foo bar! baz\?.lua", use:
set LUA_PATH="!\foo bar! baz\?.lua"
Related
In C/C++ you can use __FILE__ and __LINE__ to get access to the current file and line number.
Does Go provide something similar?
Indeed it does:
http://golang.org/pkg/runtime/#Caller
runtime.Caller can also be used to get the file name/line number of calling functions, too.
I have been trying to manually load Ruby scripts into SketchUp manually, using load. I always get an error back saying the file is non existent even though it is there in the directory.
Here is a sample of my code:
load "H:Document\sclf_color_by_z_1.6.1_1.rbz"
and the error messages:
Error: LoadError: (eval):0:in `load': no such file to load -- H:Document clf_color_by_z_1.6.1_1.rbz>
(eval)
(eval):0
Three issues here:
H:Document\sclf_color_by_z_1.6.1_1.rbz is not a valid path. After the Drive specifier H: you you should have a separator: \ - like so: H:\Document\sclf_color_by_z_1.6.1_1.rbz
Beware escape characters in strings when you program. \ is such a character.
To correct your string you'd have to have something like this:
"H:\\Document\\sclf_color_by_z_1.6.1_1.rbz"
https://en.wikibooks.org/wiki/Ruby_Programming/Strings#Escape_sequences
However, note that the convention for Ruby is to use forward slashes - even on Windows: "H:/Document/clf_color_by_z_1.6.1_1.rbz"
You are trying to load an RBZ file here. This is not the same as an RB file. An RBZ is a packaged SketchUp extension (actually a ZIP file). To programmatically install an RBZ you must use Sketchup.install_from_archive("H:/Document/clf_color_by_z_1.6.1_1.rbz")
http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchup#install_from_archive
Note that Sketchup.install_from_archive is nothing like load - it permanently installs the extension to SketchUp where as load would be just for that session.
Whenever you have a filepath that you think should be on disk - as the system whether it can find it: File.exist?("H:\Document\sclf_color_by_z_1.6.1_1.rbz") If that return false you know you need to carefully check your path again checking for syntax errors and typos.
You should use File.join() method. In your case:
You can't use load for a .rbz file but you can use Sketchup.install_from_archive() as thomthom said
So in your case your can simply do:
file = File.join( 'H:', 'Document' , 'sclf_color_by_z_1.6.1_1.rbz' )
Sketchup.install_from_archive file
I'm writing a Mac OS program, and I have the following lines:
os.execute("cd ~/testdir")
configfile = io.open("configfile.cfg", "w")
configfile:write("hello")
configfile:close()
The problem is, it only creates the configfile in the scripts current directory instead of the folder I have just cd' into. I realised this is because I'm using a console command to change directory, then direct Lua code to write the file. To combat this I changed the code to this:
configfile = io.open("~/testdir/configfile.cfg", "w")
However I get the following result:
lua: ifontinst.lua:22: attempt to index global 'configfile' (a nil value)
stack traceback:
ifontinst.lua:22: in main chunk
My question is, what's the correct way to use IO.Open to create a file in a folder I have just created in the users home directory?
I appreciate I'm making a rookie mistake here, so I apologise if you waste your time on me.
You have problems with ~ symbol. In your os.execute("cd ~/testdir") is the shell who interprets the symbol and replaces it by your home path. However, in io.open("~/testdir/configfile.cfg", "w") is Lua who receives the string and Lua doesn't interprets this symbol, so your program tries to open a file in the incorrect folder. One simple solution is to call os.getenv("HOME") and concatenate the path string with your file path:
configfile = io.open(os.getenv("HOME").."/testdir/configfile.cfg", "w")
In order to improve error messages I suggests you to wrap io.open() using assert() function:
configfile = assert( io.open(os.getenv("HOME").."/testdir/configfile.cfg", "w") )
The context: There is a map somewhere on the system with bin files which I'd like to call. They are not callable directly though, but through shell scripts which do all kinds of magic and then call the corresponding bin with: "$ENV_VAR/path/to/the/bin" "$#" (the software is non-free, that's probably why this construction is used)
The problem: Calling this from within Python. I tried to use:
from subprocess import call
call(["nameOfBin", "-input somefile"])
But this gave the error ERROR: nameOfBin - Illegal option: input somefile. This means the '-' sign in front of 'input' has disapeared along the way (putting more '-' signs in front doesn't help).
Possible solutions:
1: In some way preserving the '-' sign so the bin at the end actually takes '-input' as an option instead of 'input'.
2: Fix the magic in a dirty way (I will probably manage), and have a way to call a bin at a location defined by a $ENV_VAR (environment variable).
I searched for both methods, but appearantly nobody before me had such a problem (or I didn't see it: Sorry if that's the case).
Each item in the list should be a single argument. Replace "-input somefile" with "-input", "somefile":
from subprocess import call
rc = call(["nameOfBin", "-input", "somefile"])
I am having trouble getting constant definitions loaded via an external file. I have narrowed the problem down to the following.
require_relative '../../common/config.rb'
A_CONSTANT = 'something'
puts "A_CONSTANT: #{A_CONSTANT}"
When I run this as written, it prints the message correctly. The same constant is declared in the file common/config.rb. The relative path is correct for the location of this file. Just for completeness, the above code is in /watir/dashboard/spec/ex.rb. The constant is declared in /watir/common/config.rb.
As I see it, the above code should error out for a duplicate constant declaration. It does not. If I comment out the constant declaration above and rerun, the puts statement shows an error for 'uninitialized constant.' Any ideas what's wrong?
Edit - The contents of the file common/config.rb are below.
A_CONSTANT = 'something'
On a lark, I changed the filename to common/conf.rb. When I modify the require_relative statement to load the renamed file, I get the results I originally expected. The file is loaded and the second constant declaration throws a warning saying 'already initialized constant.' If I comment out the second declaration, the script runs perfectly.
It appears that the filename 'config.rb' is somehow special when loaded by a relative path. I have use that filename in other scripts where it was in the same folder as the loading script or a sub-folder. This is the first time I have had to move up the tree to load it.
Ruby allows redefining constants, and will only print a warning. Some setting in your Ruby is just hiding that warning from you.