I want to quit swift repl gracefully and not use ctrl-d to exit it.
For eg. python repl can be exited by typing exit(). Is there a similar way of quitting swift repl?
This answer complements Ankit Goel's correct :quit answer to also (1) provide an understanding of why the : is needed and (2) other options besides :quit.
Swift REPL works in conjuction with the LLDB debugger.
: is a REPL escape prefix to execute an LLDB command. From within REPL, :help will list the available LLDB commands.
Any of the following will quit both Swift REPL and subsequently LLDB with a single command line.
:exit
:quit
:q
One can also exit REPL into LLDB with just : and, then later quit (or exit) using the LLDB command directly.
sh$ swift
Welcome…
1> print(18 + 4)
22
2> :
(lldb) print "hello"
(String) $R0 = "hello"
(lldb) quit
sh$
Addendum: The LLDB command c or continue can be used to return to the Swift REPL environment.
Just found out that a graceful way to quit swift repl is by using typing :quit
It does not work without the colon.
Related
In .lldbinit in macOS 10.13.3 I define an alias:
command alias pl process launch --stop-at-entry --
so that inside lldb run from the command line I can say something like:
pl ~/path-to-filename
However, when I examine argv I see that lldb has not performed path expansion on the ~.
Of course, the session fails, lldb can't find the file, but if at the bottom I rerun the session with r, the ~ resolves to the absolute path.
The alias is not the issue because if I run process launch inside lldb
with:
process launch --stop-at-entry -- ~/path-to-filename
lldb still refuses to resolve ~. And, it seems bizaare to me, lldb does the expected right thing, resolve ~, when doing r to rerun the debug session. Is this a bash issue, a bug in lldb, a feature or pilot error? I don't know whether this behavior also occurs in the Xcode gui, because I don't use it. It makes me wan't to barf.
(lldb) help pro lau
Launch the executable in the debugger.
[...]
-X <boolean> ( --shell-expand-args <boolean> )
Set whether to shell expand arguments to the process when launching.
(lldb) help r
'r' is an abbreviation for 'process launch -X true --'
I use gdb in emacs.
The "command" command is used to set commands to be executed when a breakpoint is hit.
It should return when I type "end" as below, but nothing happened.
But when I use gdb in shell, it is ok.
So who can tell me why?
I am using SML NJ v110.78 on Mac OS X 10.9. I am trying to use command-line arguments from BASH, like so:
sml progname.sml 2.0 1.0.
The program progname.sml compiles and runs and uses the command-line arguments to produce a value (using SMLofNJ.getArgs() function), but at the end of the processing, the REPL returns the error:
!* unable to process `2.0' (unknown extension `0')
!* unable to process `1.0' (unknown extension `0')
-
How do I avoid those final error messages?
Thank you.
You need to terminate the REPL with an exit statement:
val _ = OS.Process.exit(OS.Process.success);
When you don't exit the REPL in above manner then the command-line arguments are regarded by the interpreter as compiler extensions, hence the feedback:
!* unable to process `2.0' (unknown extension `0')
BTW: You can use OS.Process.exit(OS.Process.success); to exit the REPL as a cleaner alternative to CTRL+Z
How do I quit SML?
ML Command Line Options Cheat Sheet
If I write a Scala script (or App) that just prints out the command line arguments, I notice that it ignores all the '!' characters. For example, if my script looks like:
println(args(0))
And I run it with:
scala MyScript "Hello!"
I get the output:
Hello
And if I run it with:
scala MyScript "Hello! World!"
I also get:
Hello
What's going on? What is the purpose of the ! character in arguments that causes this behaviour?
! is history substitution.
Try scala MyScript hello! with ! at EOL to see it work as if quoted.
http://www.gnu.org/software/bash/manual/bashref.html#Event-Designators
http://www.gnu.org/software/bash/manual/bashref.html#Single-Quotes
On windows, the "scala.bat" command script has delayed expansion enabled.
http://en.wikibooks.org/wiki/Windows_Batch_Scripting
http://en.wikibooks.org/wiki/Windows_Batch_Scripting#SETLOCAL
http://en.wikibooks.org/wiki/Windows_Batch_Scripting#Command-line_arguments
To disable interpretation of !myvar!:
C:\Users\you> scala greeting.script "hello^!"
hello!
C:\Users\you> set world= Bob
C:\Users\you> scala greeting.script "hello!world!"
hello Bob
I'm using the Scala REPL to interactively test some hash functions I'm building. I'm constantly switching between the product code (Eclipse), the browser and the Scala interpreter, doing copy/paste of values and results. In the mix I'm often doing CTRL-C on the interpreter, exiting the session and loosing all my functions.
Is there any way to let the Scala REPL either ignore CTRL-C or, even better, perform "paste" with it? I'm working on Linux.
I only know how to prevent REPL from exiting. Remapping of CTRL+C to perform copy command could be done in the same way (if there is some command that ables to change keymap w/out restarting terminal -- I don't know is there one). Anyways, to block ^C wrap your REPL invocation in .sh script like this:
#!/bin/bash
#switch off sensitivity to ^C
trap '' 2
# here goes REPL invoke
scala
#get back sensitivity to ^C
trap 2
trap command
defines and activates handlers to be run when the shell receives
signals
or other conditions.
2 is a SIGINT value (that's the signal which is triggered when you press CTRL+C)
The repl already intercepts ctrl-C, but apparently it doesn't work on linux. It does work on osx. If someone who uses linux opens a ticket with sufficient detail to indicate why not, I can fix it.
As an alternative to the native Scala REPL, you can use Ammonite, which does handle Ctrl+C:
# while(true) ()
... hangs ...
^Ctrl-C
Interrupted!
#
The traditional Scala REPL doesn't handle runaway code, and gives you no option but to kill the process, losing all your work.
Ammonite-REPL lets you interrupt the thread, stop the runaway-command and keep going.