In python, I can run a script and enter interactive mode in the context of that script. This lets me mess with global variables and what not to examine program state.
$ python -i hello.py
Can I do this with Coffeescript? I've tried the following:
$ coffee -i hello.coffee
doesn't load hello.coffee. It's equivalent to coffee -i
$ cat hello.coffee | coffee -i
runs the script line by line in REPL but ends REPL after the EOF.
I've recently started a project to create an advanced interactive shell for Node and associated languages like CoffeeScript. One of the features is loading a file or string in the context of the interpreter at startup which takes into account the loaded language.
http://danielgtaylor.github.com/nesh/
Example:
# Load a string
nesh -c -e 'hello = (name) -> "Hello, #{name}"'
# Load a file
nesh -c -e hello.coffee
Then in the interpreter you can access the hello function. Also a good idea to create an alias in bash:
alias cs='nesh -c'
cat foo.coffee - | coffee -i
tells cat to first output your code and then output stdin, which gives you what you're looking for I think.
I am confronted with this problem as well. The one provide by #int3 doesn't solve this problem, for CoffeeScript is one indentation based language. stdin will pass the code line by line, but the repl is not smart enough to realize this. Since you post this question, I suggest you create one issue (feature request) on CoffeeScript
Related
I'm trying to use named pipes in a project. I have two terminals open, Terminal A and Terminal B.
In terminal A, I issued this command:
mkfifo myFifo && tail -f myFifo | csh -s
It seems as if standard out is being redirected somewhere else, though, because my prompt disappears and some commands aren't reflected in terminal A.
For example, if in terminal B I begin a python session via issuing echo "python" > myFifo, then echo "print 'Hello, World'" > myFifo, I don't see Hello, World in terminal A.
However, if I issue echo ls > myFifo within terminal B, I see the correct output from ls in terminal A.
Does anyone know why sometimes the output appears and sometime it doesn't?
I'm running on CentOS 6.6
Thanks,
erip
You read from the FIFO with csh, if you start an interactive Python shell in csh, then it won't be reading from the FIFO because it's busy running python.
Python doesn't somehow automagically do a REPL on the FIFO. How should it even know about the FIFO? It has no knowledge of it.
You could, perhaps, tell Python to read commands from the FIFO with something like:
>>> import os, sys, time
>>> fifo = open(os.open('myFifo', os.O_NONBLOCK), 'r')
And then:
$ echo 'print(42+5)' > ! myFifo
Will give you:
>>> eval(fifo.read())
47
Perhaps there's also a way to tell Python to read commands from myFifo by overwriting sys.stdin, but I can't get that working in my testing.
It's a bit unclear to me what exactly you're trying to achieve here, though. I suspect there might be another solution which is much more appropriate to the problem you're having.
In case of "ls" command it runs with and without the prefix "!". In case of "cat fileName" it's the same, but when you consider "wc -l fileName" it works only with "!" prefix.
When you combine cat and wc command "cat fileName | wc -l" executed successfully without "!" prefix.
I don't understand the logic behind this prefix "!" in ipython.
Thank you in advance
(I am new to python programming, if it sounds silly question please forgive me.)
IPython tries to make interactive programming as comfortable as possible. Some shell builtins like ls, cd or cat are basic commands to navigate in unix shells. IPython, as a "Python Shell" provides the same functionally for convenience. Along with features like colored output, etc.
The !command is for executing arbitrary shell code and is much more powerful. It can be used to run any command you can type in a normal shell and can also catch its output.
Compare ls with !ls. The former will print the content in your current directory with nice coloring. The latter will print the same list, but just plain text.
But note that you can do really cool things with !command:
files = !ls
for f in files:
print("I like this file:", f)
Which reads the output of ls into a python array files which you can use in your code just like any other array.
To sum up: if you just want to navigate, you usually use the standard commands, if available. If you need to capture the output or run programs you have to use the !command syntax.
I'd love to be able to do something like:
perl -d my-program.pl -c 'b postpone Foo::Bar::some_func'
i.e. specify as part of the invocation of perl -d a command that I would ordinarily enter at the debugger prompt, namely b postpone Foo::Bar::some_func.
From man perldebug, you could use source file
Put some common commands in a file and source that manually after starting the debugger.
I have a makefile for compiling Arduino programs.
I need to add some text at the beginning of some files based on some logic. I am using echo command for that.
ECHO = echo
and later in the file, I have lot of places like
$(OBJDIR)/%.cpp: %.pde
$(ECHO) '#if ARDUINO >= 100\n #include "Arduino.h"\n#else\n #include "WProgram.h"\n#endif' > $#
which works fine.
Recently, some users complained that echo command doesn't work properly in some linux distros and I had to add the '-e' option to the echo command.
So I changed the first line where I declare the command to
ECHO = echo -e
This is not working, because makefile considers -e as part of the text and not as part of the option.
Edit:
I am not getting any error, but the text -e is also appended to the file that I am creating.
Is there a way to declare the -e as an option and not as part of the text?
Most likely you're seeing behavior differences because echo is a shell built-in command in some versions of some shells. Then that's being compounded because make only sometimes uses the shell to invoke commands -- it will prefer to invoke commands directly if possible. So, sometimes, on some systems, you are not invoking the echo command that you think you are.
You would probably have better luck by setting
ECHO = /bin/echo -e
which will explicitly invoke the external echo command, even if the shell has a built-in version. That way you should get consistent results.
if get /bin/sh: 1: -e: not found error it's related to your shell, not makefile.else, please put your error. of course if you get error.
I tried the following:
$ cat args.sh
\#! /Applications/ccl/dx86cl64
(format t "~&~S~&" *args*)
$ ./args.sh
Couldn't load lisp heap image from ./args.sh
I can run lisp fine directly:
$ /Applications/ccl/dx86cl64
Welcome to Clozure Common Lisp Version 1.5-r13651 (DarwinX8664)!
?
Is it possible to write a shell script to run lisp code with Clozure CL? I am sure I am doing something silly.
I installed it from: http://openmcl.clozure.com/
Just following up on Charlie Martin's answer and on your subsequent question. The dx86cl64 --eval <code> will fire up a REPL, so if you want to fire up a given script then quit, just add this to the end of your script: (ccl::quit). In the example you provided, this would do the trick:
#! /bin/bash
exec /Applications/ccl/dx86cl64 --eval '(progn (format t "hello script") (ccl::quit))'
A nicer script would be the following:
#! /bin/bash
exec /Applications/ccl/dx86cl64 -b -e '(progn (load "'$1'") (ccl::quit))'
Put that into a file, load-ccl-script.sh (or other name of your choice). Then the following interaction works:
$ echo '(format t "weeee!")' > a.lisp
$ sh load-ccl-script.sh a.lisp
weeee!
$ _
The issue is in your shebang line:
\#! /Applications/ccl/dx86cl64
In a UNIX file, the first 16 bits is called the "magic number". It happens that the magic number for an executable script is the same bit configuration as the characters "#!". The first 16 bits of your file have the same configuration as "\#", and UNIX won't buy that.
It is possible to add magic numbers, but it isn't easy or portable, so what you need is a way to invoke the script. I'd suggest
#! /bin/bash
exec /Applications/ccl/dx86cl64
with appropriate arguments etc for your script. (The exec builtin causes the current process to be loaded with the named executable without forking, so you don't have a spare process lying about.)
Update
In your particular case, you'll want something like
#! /bin/bash
exec /Applications/ccl/dx86cl64 --eval '(format t "~&~S~&" *args*)'
See the command line args for Clozure for why.
You have to make sure, that the kernel can load a Lisp memory image. The default behaviour is for the kernel to look for a file, which is named like the kernel binary with ".image" appended, i.e., if you start CCL using dx86cl64, then the image loaded is dx86cl64.image from the same directory. You can modify this behaviour by supplying the image explictely using the --image option. Try dx86cl64 --help for more information.
See the scripts subdirectory of your ccl directory. It should have some scripts you can adapt and use.
You cannot call the script like this from the command line:
/Applications/ccl/dx86cl64 myscript
can you?
I think that you need to call it like this (I don't have Clozure CL here, so I can't test):
/Applications/ccl/dx86cl64 -b -l myscript
So, your script should start like this:
#!/Applications/ccl/dx86cl64 -b -l
...