Friends,
I'm trying to set the environment variable "asdf" in my Scala shell, as described here
These are my commands:
scala> import scala.sys.process.Process
import scala.sys.process.Process
scala> Process(Seq("bash", "-c", "echo $asdf"), None, "asdf" -> "Hello, world!").!
Hello, world!
res18: Int = 0
But when i try to read the environment variable back:
scala> sys.env.get("asdf")
res19: Option[String] = None
The output says "None". How do i properly set my environment variable in the current session?
PS - Please do not downvote this; i'm trying really hard but unable to get past my issue
It has nothing to do with Scala, you are just misunderstanding the situation. The map at the end of the line
scala> Process(Seq("bash", "-c", "echo $asdf"), None, "asdf" -> "Hello, world!").!
doesn't change the environment of of this process, the one you are typing into; it changes the environment of the child process that the Process() function creates.
It is not permitted for a Scala/Java process to modify its own environment. You can use the scala.util.Properties object to inspect environmental variables and properties. (Docs are here.) The properties can be added/removed/changed but the environmentals cannot.
Related
Inside a program - not the REPL - is it possible to introduce a string variable to represent the shell command to be executed ?
import sys.process._
val npath = opath.substring(0,opath.lastIndexOf("/"))
s"rm -rf $npath/*" !
s"mv $tmpName/* $npath/" !
The compiler says:
:103: error: type mismatch;
found : String
required: scala.sys.process.ProcessLogger
s"mv $tmpName/* $npath/" !
^
Note that in the REPL this can be fixed by using
:power
But .. we're not in the REPL here.
I found a useful workaround that mostly preserves the intended structure:
Use the
Seq[String].!
syntax. But by using spaces as a delimiter we can still write it out in a kind of wysiwig way
import sys.process._
val npath = opath.substring(0,opath.lastIndexOf("/"))
s"rm -rf $npath/*".split(" ").toSeq.!
s"mv $tmpName/* $npath/".split(" ").toSeq.!
The limitation here is that embedded spaces in the command would not work - they would require an explicit Seq of each portion of the command.
Here is a bit nicer if there were a set of commands to run:
Seq(s"rm -rf $npath/*",s"mv $tmpName/* $npath/").foreach{ cmd=>
println(cmd)
cmd.split(" ").toSeq.!
}
I am running Spark-Shell with Scala and I want to set an environment variable to load data into Google bigQuery. The environment variable is GOOGLE_APPLICATION_CREDENTIALS and it contains /path/to/service/account.json
In python environment I can easily do,
import os
os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = "path/to/service/account.json"
However, I cannot do this in Scala. I can print out the system environment variables using,
scala> sys.env
or
scala> System.getenv()
which returns me a map of String Key,Value pairs. However,
scala> System.getenv("GOOGLE_APPLICATION_CREDENTIALS") = "path/to/service/account.json"
returns an error
<console>:26: error: value update is not a member of java.util.Map[String,String]
I found a work around for this problem, though I dont think its the best practice. Here is the 2 step solution for this -
From terminal/cmd, first create the environment variable -
export GOOGLE_APPLICATION_CREDENTIALS=path/to/service/account.json
From the same terminal window, open spark-shell and run -
System.getenv("GOOGLE_APPLICATION_CREDENTIALS")
I'm trying to do sbt flywayMigrate -Denvi=foo but the system property envi is not being set. Pointers for debugging is greatly appreciated as I haven't been successful in identifying the cause of this issue for hours now. No question in SO or anywhere else have had this issue so far.
In build.sbt, this will be used as a variable.
lazy val envi = sys.props.getOrElse("envi", "default")
Using sys.env.get("ENVI") instead is currently not an option due to shared/team repo considerations.
sbt console -Denvi=foo
scala> sys.props.get("envi")
res0: Option[String] = None
scala> sys.props.getOrElse("envi", "default")
res1: Option[String] = default
scala, sbt installed using brew
You have to put the environment variable before the command:
sbt -Denvi=foo console
otherwise it will be passed as an argument to the main class instead of to the JVM.
Alternatively you can set the environment in the JAVA_OPTS variable before starting sbt:
export JAVA_OPTS="-Denvi=foo"
sbt console
scala> sys.props.getOrElse("envi", "default")
res0: String = foo
I want use Scala like Python, so I install REPL in Sublime Text(Os is win8)
Everytime in REPL, I have to
scala> :load <my file>
, so I think it's inconvenient.
And I can't change
scala> :settings -d <路径名>
in Chinese directory.
I'm confused whether I can't change Scala script's directory with non-english language.
Thanks a lot!
If you use sbt then you can define initial commands when you launch the console.
yourproject/build.sbt:
// build.sbt
name := "initial-commands-example"
initialCommands := "import Foo._"
yourproject/script.scala:
// script.scala
object Foo {
def hello(name: String) = s"hello $name"
val msg = hello("world")
}
Inside yourproject, run sbt console, and you will have everything in Foo available inside that repl. See sbt initialCommands docs for more information.
I have the Akka microkernel below:
class ServiceKernel extends Bootable {
val system = ActorSystem("service-kernel")
def startup = {
system.actorOf(Props(new Boot(false))) ! Start
}
def shutdown = {
system.shutdown()
}
}
Because the kernel extends Bootable and not App, how would I access command line arguments used when starting the kernel? For instance if I run the kernel using start namespace.ServiceKernel -d rundevmode or similar. Thanks!
Additional Info
I thought it would be worth adding this information about the start up script in the microkernel. In /bin/start you notice the following:
#!/bin/sh
AKKA_HOME="$(cd "$(cd "$(dirname "$0")"; pwd -P)"/..; pwd)"
AKKA_CLASSPATH="$AKKA_HOME/config:$AKKA_HOME/lib/*"
JAVA_OPTS="-Xms256M -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:ParallelGCThreads=2"
java $JAVA_OPTS -cp "$AKKA_CLASSPATH" -Dakka.home="$AKKA_HOME" akka.kernel.Main "$#"
Although om-nom-nom originally suggested -D options, it looks like it's in use and the main start up parameter is being passed to the akka.kernel.Main class (which in this case would be the ServiceKernel class above).
Here is the minimal example:
object Foo extends App {
val debugModeOn = System.getProperty("debugmode") != null
val msg = if (debugModeOn) "in debug mode" else "not in debug mode"
println(msg)
}
» scala Foo -Ddebugmode
in debug mode
» scala Foo
not in debug mode
You can do extra check to overcome this issue:
» scala Foo -Ddebugmode=false
in debug mode
P.S. you might also want to use Properties helper, that contains bunch of methods like propOrNone, propOrElse, etc
It looks like in the sh script that they give you an opportunity to provide JAVA_OPTS, and if not, they give you one that they pre-define. I suppose you could just set JAVA_OPTS in a script that then calls this one, specifying a -D option for your custom args in the JAVA_OPTS. That way you can be sure your custom args get passed in via the -D system property you specify. Hackish but I think it should work. The beauty of -D is that you can supply as many as you want, so the fact that they are already using it for some of their own system properties should not matter.