Let's say I have a Dart script called dart-test. I would like to distribute this script and make it so that users just have to put it in a folder in their $PATH, and execute it from anywhere just by typing dart-test in their terminal.
For the sake of this question, let's pretend I am the user test on my machine. I am on Mac OS X and installed the Dart binary with Homebrew. The dart binary lies in /home/test/.brew/bin and is in the $PATH.
Consequently, the following works:
$ cat <<HEREDOC > ~/.brew/bin/dart-test
#!/home/test/.brew/bin/dart
main() => print('Dart shebang works!');
HEREDOC
$ chmod u+x ~/.brew/bin/dart-test
$ dart-test
Dart shebang works!
The problem is that the Dart shebang I use is not portable, my script won't work on any other computer than mine. Is there a portable way to do this?
(Considering Dart is kind of like Python and Ruby in the way it executes, I just looked at the standard way of doing it in those two languages. The env binary.)
#!/usr/bin/env dart
Seems to be the way. It will look for dart binaries in the user's environment, and apparently enables simple Dart scripts to be executed from anywhere, provided the Dart VM is installed and in the $PATH.
Related
When I try to run a shell command in ipython or the julia repl it just says
shell> ls
zsh:1: command not found: ls
Not sure if it matters, but I have my path set in zshenv instead of zshrc so that emacs shell works.
Any ideas?
Edit:
I'm on macOS 10.14.6
For Julia, The shell> REPL prompt does in fact use a shell to execute its commands (on non-Windows systems). It effectively does something like run(`$shell -c ls`), and for most shells (including zsh) this means "non-interactive" mode and limits the number of init files that get loaded. You want to make sure your shell is working in this mode; I'd guess that if you type zsh -c ls at your terminal it'll be similarly broken.
Alternatively, you can customize which shell Julia uses through an environment variable. Setting JULIA_SHELL=/bin/sh is probably a safe bet — Julia uses that environment variable if it is set, otherwise it uses SHELL, and finally it falls back to /bin/sh if neither is set.
I'm not as familiar with ipython, but I'd wager it's doing something similar.
So I'm trying to use lua on Windows.
I've installed with the LUA Windows Installer and ended up trying on git bash but the command lua isn't recognized.
I've tested on my CMD since my environment variable are set and it works on CMD.
Can't seem to make it work on Git Bash.
I took the binaries available at the time (5.3.5) and put everything in a 5.3.5 folder inside my Lua folder.
Renamed lua53 in lua. Changed my PATH environnement variable to be
And voilà
How i can automatically run some script on lua without bat/shortcut, when i start interpreter? M.b. lua have some reserved file names like autorun or autoexec?
Just skip following text. Its for validator.
For portable use you can create bat file. Its dont like to me, but it works:
luajit.exe %~dp0%~n0.lua
that .bat run script with same name.
my_name.bat - run my_name.lua
123.bat - run 123.lua
Its not perfect but idk another decision.
I'm new to using Window's Command Prompt, and also to developing with Ruby on Rails. Possibly a silly question but one that I'm sure everyone who learns with CodeCademy will end up asking; right now I'm prefixing every command for my project with 'Jruby -S ...", for example:
C:\users\MyName\MyProject> Jruby -S rails new MyApp
...
C:\users\MyName\MyProject> Jruby -S bundle install
...
C:\users\MyName\MyProject> Jruby -S rake db:migrate
Can I use some kind of alternative shell to save me typing Jruby -S every time? I'm aware of bash and powershell but have basically zero knowledge of whether I should be using them...
Thanks folks!
EDIT
Lots of helpful suggestions below, but I was really looking for a shell to mimic the functionality of the console on codecademy.com (which I believe is supposed to work like a Mac's 'bash' program?). Thanks anyway.
I'm new to using Window's Command Prompt
The CMD works very similarly to the GUI/Shell -- you have to call applications and then run commands with them.
The difference between CMD and windows is that CMD is "naked" - you have to ensure all the paths are correct, and that you're calling the correct application each time.
For example, calling rails server literally translates as:
Program = ruby.exe / rails
Command = server
CMD uses the PATH environment variable to make this process smoother.
The PATH var basically allows you to reference applications on your computer from the CLI (command line interface). This means that if you have an application (EG ruby.exe), you can add the ruby.exe directory to your PATH variable, allowing you to call ruby ... straight from cmd.
--
In your case, I don't have much experience with JRuby; I do know, however, that if you want to invoke the functionality of that application, you have to call it from the cli.
Hopefully my answer gives some context.
You can do that with powershell.
I'm sure that there should be a better way to do that, but you can try this
$ruby = "Jruby"
$s = "-S"
& $ruby $s rails new MyApp
I don't work on windows, however the jruby zip files on the download site have a bin directory with .bat and .exe files for jruby, rake, and gem. You could just add the directory you installed jruby to and the 'bin' subdirectory to your PATH to start.
set JRUBY_HOME= your_installed_jruby
set PATH= %PATH%;%JRUBY_HOME%\bin
http://jruby.org/download
I don't know what the windows installer does, but I would think it would do something similar.
I wasn't able to run ./script/console previously, and it used to throw an error since my script console file had included #!/usr/bin/env ruby19. After doing hit and trial I fixed this error by replacing #!/usr/bin/env ruby19 with #!/usr/bin/env ruby.
What does the above line do?
Versions:
Ruby: 1.9.2-p180
Ruby on Rails: 2.3.5
The #! (hash bang) in the first line of a text file tells the program loader in most *nix systems to invoke the program that is specified next (in this case, /usr/bin/env) with any params supplied (in this case, ruby).
/usr/bin/env is just a portable way of looking in your environment for program named in the first argument. Here it is the Ruby interpreter. If the Ruby interpreter is in your PATH, env will find it and run it using the rest of the file as input.
You probably didn't have a program named ruby19 in your PATH, so you'd get the error. You do have a program named ruby, so that works.
The shebang line in a Unix script is supposed to specify a full path, so this:
#!/usr/local/bin/ruby
is valid but this is not:
#!ruby
The problem with the first form is that, well, you need to use a full path but the actual path won't be the same on all systems. The env utility is often used to allow a script to search the PATH environment variable for the appropriate interpreter, env should always be in /usr/bin/env so you can safely use that as a full path and then let env search the PATH for the named interpreter.
From the fine manual:
env [-i] [name=value]... [utility [argument...]]
The env utility shall obtain the current environment, modify it according to its arguments, then invoke the utility named by the utility operand with the modified environment.
That isn't terribly helpful in your case but I figured I should include it anyway. The shebang use of env is a bit of a hack that doesn't use the intended behavior of env.