Regarding the cross platform nature of rlwrap, at the cost of an extra JVM dependency might it not be better to use jline?
http://jline.sourceforge.net/ https://github.com/jline/jline3 I used to use it with clojure many many years ago and it seemed to work quite well... R. On 26 July 2017 at 17:57, Alex Miller <a...@puredanger.com> wrote: > > > On Wed, Jul 26, 2017 at 11:48 AM, Steve Miner <stevemi...@gmail.com> > wrote: > >> I’ve been using my own launch script that does something similar to the >> new clj script. (I’m caching a Leiningen generated classpath.) I had some >> bugs when my project directory was copied to another user or machine >> because the cached classpath was not validate in the new environment, >> particularly with a different Maven repository. The same kind of problem >> can happen with a remotely mounted project directory. File time checks did >> not necessarily protect against these relocations. >> >> I fixed my problem with two changes. First, I put the cache in the >> PROJECT/target subdirectory so that a “lein clean” would allow the user to >> recover. >> > > This is a non-starter - we need the cache to survive a rebuild by separate > build tool (also don't want to create target dir if not needed). > > >> Second, I named my cache file with the inode of the project.clj file. If >> the project is copied somewhere else, it is highly unlikely that the inode >> numbers would match. The inode of the Maven repository or project deps.edn >> should work with the new clj script. >> > > Interesting, will think about that (portability issues though). > > >> I use rlwrap, except within an Emacs shell. I suggest you test for the >> presence of rlwrap as you do for java. $(type -p rlwrap) and ignore it if >> it’s not found. I think Emacs is popular enough that it’s worth testing >> for within your clj script ($EMACS will be defined). It would be good >> enough if you provided an option to turn off rlwrap so I could wrap your >> script with my own. >> > > I've had feedback from others on rlwrap too (since it's currently missing > from the installation instructions, which is just my oversight). The idea > was that the installer would ensure it's installed so it can be assumed it > exists. But there are surely cases where you might not want it so a jira > for having a way to add more control around it would be fine. I don't want > to check for $EMACS but wouldn't mind having a new env var that you could > set to skip it or something like that. > > >> I can file bugs and provide patches if you want. >> >> Steve Miner >> stevemi...@gmail.com >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
