cd! is not found in script

[jeffdyke]

Hello, i have completely blown away my ammonite installation of 0.7.0 and am upgrading to 0.7.8, i have cleared the entire ~/.ammonite directory as well as removing the amm binary, in the shell with the predef.sc downloaded cd! works correctly, in this simple script it gives the following error.

cat TestCd.sc

import ammonite.ops._
import ammonite.ops.ImplicitWd._

cd! root/'Users/'jeff

amm TestCd.sc
Compiling TestCd.sc
TestCd.sc:4: not found: value cd
val res_2 = cd! root/'Users/'jeff
            ^
Compilation Failed

amm
Loading...
Welcome to the Ammonite Repl 0.7.8
(Scala 2.11.8 Java 1.8.0_101)

I know this will be simple and it seems odd that it compiles in other scripts, before and after the clearing of the cache, so that is when i reduced my issue to this simple set of commands and in this case i likely do not need ImplicitWd._

Thanks!
Jeff

[jeffdyke]

not surprising, but this works, but fails later when you try to use % or %% b/c of ambiguous Implicits

cat test.sc

#!/usr/bin/env amm
interp.load.ivy("com.lihaoyi" %% "ammonite-shell" % ammonite.Constants.version)
@
val shellSession = ammonite.shell.ShellSession()
import shellSession._
import ammonite.ops._
import ammonite.ops.ImplicitWd._
cd! root/'src/'code
println(wd) // "/src/code"

I just want to know if i can use cd! in scripts and if i can't, why and how do i work around this, cd'ing into directories is critical for scripts especially a build script, which is what i'm using Ammonite for mostly.

Thanks
Jeff

[jeffdyke]

Thanks for the fix on the ambiguous imports. Do you have any comments on the original issue? This was simply a hack to try to get around the issue temporarily. This is reproducible on a completely new machine after installing 0.7.9 Thanks!

[jeffbondlink]

Sorry should have written about this a while ago, the fix for this, at least one without a code change is to create a predefScript.sc that can look identical to predef.sc minus the instantiation of the repl(last line as of 0.8.0). This has been working nicely on 0.8.0. For people interested in where this information is, you can dig into the Internals Documentation, specifically: (predef)[https://github.com/lihaoyi/Ammonite/blob/master/internals-docs/predef.md]

Thanks @lihaoyi and contributors for a very helpful product. Please feel free to close this as i don't believe i can.

[lihaoyi]

cd isn't a member of ammonite.ops; if you want to perform operations in a different directory, define a val newPath = ... and use that in your operations. cd is only available as part of the ammonite shell, as described in http://www.lihaoyi.com/Ammonite/#Ammonite-Shell

[jeffdyke]

Thanks but the real issue, and it was solved in other ways in the change in behaviour between 0.7.6 and 0.8.0, from memory, responding only so if people try to upgrade

[gnoireaux]

cd is only available as part of the ammonite shell, as described in http://www.lihaoyi.com/Ammonite/#Ammonite-Shell

Is there an imperative technical reason for ammonite-shell and ammonite-script to differ?
Changing directories is quite basic for scripting.
Hard work was invested in making the repl nice and accessible and concise, why squander it by depriving ammonite-script from cd ?

[jeffdyke]

@gnoireaux - i realize this does not answer your inquiry, but as i use cd! quite often in ammonite scripts, i thought i'd share. I started with importing it, import ammonite.shell._ directly inside the script, but then moved to adding a predefScript.sc in ~/.ammonite/that contains everything the shell does except for configuring the shell and it works very well. I've been using ammonite for a bash replacement where i need more control/safety, socd` was an absolute requirement.

interp.load.ivy(
  "com.lihaoyi" %
  s"ammonite-shell_${scala.util.Properties.versionNumberString}" %
  ammonite.Constants.version
)
@
val shellSession = ammonite.shell.ShellSession()
import shellSession._
import ammonite.ops._
import ammonite.shell._

There could probably be less in this file, but ... if it ain't broke...

[jeffdyke]

whoops i guess i basically said the same above, oh well now it's states exactly what i have.