%pgrep("java") results in mysterious

[bbarker]

When trying to run pgrep on java in amm shell, I get the following result (but note that running it on top works):

brandon-brandon@ %pgrep("java")
ammonite.ops.InteractiveShelloutException
  ammonite.ops.Shellout$.executeInteractive(Shellout.scala:53)
  ammonite.ops.Shellout$.$anonfun$$percent$1(Shellout.scala:14)
  ammonite.ops.Shellout$.$anonfun$$percent$1$adapted(Shellout.scala:14)
  ammonite.ops.Command.applyDynamic(Shellout.scala:105)
  $sess.cmd22$.<init>(cmd22.sc:1)
  $sess.cmd22$.<clinit>(cmd22.sc:-1)

brandon-brandon@ %pgrep("top")
8430

In this case, the java process in question is the amm process, so I wonder if this has something to do with amm trying to access itself in a way that isn't allowed? Running pgrep from another shell works.

brandon@freebsd:~ % ps gax | grep java
8350  1  R+      0:00.00 grep java
8068  3  I+      0:42.04 /usr/local/openjdk8/bin/java -jar -Xmx500m -XX:+UseG1GC /usr/local/bin/amm
brandon@freebsd:~ % pgrep java
8068

I tried to look at "ex.result", taking a clue from #489, but I don't see result as a member of the exception object:

def getCmdExc: Either[CommandResult, ShelloutException] = {
                            try {
							    Left(%%pgrep("java"))
							}
                            catch {
                                 case ex: ShelloutException => Right(ex)
                            }
                 }		 

A bit of inspection results in the following:

brandon-brandon@ ex.right.get.result
res20: CommandResult =
brandon-brandon@ ex.right.get.getStackTrace
res21: Array[StackTraceElement] = Array(
  ammonite.ops.Shellout$.executeStream(Shellout.scala:88),
  ammonite.ops.Shellout$.$anonfun$$percent$percent$1(Shellout.scala:15),
  ammonite.ops.Command.applyDynamic(Shellout.scala:105),
  $sess.cmd18$.getCmdExc(cmd18.sc:3),
  $sess.cmd19$.<init>(cmd19.sc:1),
  $sess.cmd19$.<clinit>(cmd19.sc),
  $sess.cmd19.$main(cmd19.sc),
  sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62),
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43),
  java.lang.reflect.Method.invoke(Method.java:498),
  ammonite.runtime.Evaluator$$anon$1.evalMain(Evaluator.scala:106),
  ammonite.runtime.Evaluator$$anon$1.$anonfun$processLine$3(Evaluator.scala:140),
  ammonite.util.Catching.map(Res.scala:111),
  ammonite.runtime.Evaluator$$anon$1.$anonfun$processLine$2(Evaluator.scala:136),
  ammonite.util.Res$Success.flatMap(Res.scala:58),
  ammonite.runtime.Evaluator$$anon$1.processLine(Evaluator.scala:134),
  ammonite.interp.Interpreter.$anonfun$evaluateLine$4(Interpreter.scala:291),
  ammonite.interp.Interpreter.withContextClassloader(Interpreter.scala:250),
  ammonite.interp.Interpreter.$anonfun$evaluateLine$3(Interpreter.scala:286),
  ammonite.util.Res$Success.flatMap(Res.scala:58),
  ammonite.interp.Interpreter.$anonfun$evaluateLine$1(Interpreter.scala:280),
  ammonite.util.Catching.flatMap(Res.scala:109),
  ammonite.interp.Interpreter.evaluateLine(Interpreter.scala:279),
  ammonite.interp.Interpreter.$anonfun$processLine$9(Interpreter.scala:237),				 

My original query was on SO.

[lihaoyi]

Huh seems to work for me

lihaoyi ~$ amm
Loading...
Welcome to the Ammonite Repl 0.8.1
(Scala 2.12.1 Java 1.8.0_112)
@ import ammonite.ops._, ImplicitWd._
import ammonite.ops._, ImplicitWd._
@ %pgrep("java")
18355
43275
45012
45049
45050

This is on OSX

No idea why it's blowing up on your machine

[bbarker]

I was on FreeBSD; I'll test a bit more on it and Linux and see what I find.

[bbarker]

So far, I can confirm that this works on all my tests on Linux: Oracle JDK or openjdk 8. I have tested on two different freebsd systems and both have the same issue (both using openjdk 8). So it seems to be FreeBSD specific.

Any other FreeBSD 11 + amm (or at least FreeBSD + Scala) users that might be worth talking to?

[bbarker]

I seem to have confirmed that it is something to do with being self-referential:

bash:

[freebsd@debug ~]$ ps gax | grep java
  680  -  Is       0:00.00 /usr/local/bin/jsvc -java-home /usr/local/openjdk8 -server -user www -pidfile /var/run/tomcat8.pid -wait 30 -outfile /usr/local/apache-tomcat-8.0/logs/catalina.out -errfile &1 -classpath /usr/local/apache-tomcat-8.0/bin/bootstrap.jar:/usr/local/share/java/classes/commons-daemon.jar:/usr/loca
  681  -  S       31:45.80 /usr/local/bin/jsvc -java-home /usr/local/openjdk8 -server -user www -pidfile /var/run/tomcat8.pid -wait 30 -outfile /usr/local/apache-tomcat-8.0/logs/catalina.out -errfile &1 -classpath /usr/local/apache-tomcat-8.0/bin/bootstrap.jar:/usr/local/share/java/classes/commons-daemon.jar:/usr/loca 40084  1  I+       1:04.45 /usr/local/openjdk8/bin/java -jar -Xmx500m -XX:+UseG1GC /usr/local/bin/amm
40465  2  S+       0:00.00 grep java
[freebsd@debug ~]$ pgrep -f "java"
40084
681
680

amm:

freebsd-freebsd@ %pgrep("-f","tomcat")
681
680

freebsd-freebsd@ %pgrep("-f", "java")
681
680

freebsd-freebsd@ %pgrep("-f", "amm")
ammonite.ops.InteractiveShelloutException
  ammonite.ops.Shellout$.executeInteractive(Shellout.scala:53)
  ammonite.ops.Shellout$.$anonfun$$percent$1(Shellout.scala:14)
  ammonite.ops.Shellout$.$anonfun$$percent$1$adapted(Shellout.scala:14)
  ammonite.ops.Command.applyDynamic(Shellout.scala:105)
  $sess.cmd6$.<init>(cmd6.sc:1)
  $sess.cmd6$.<clinit>(cmd6.sc:-1)

[lihaoyi]

Seems like more of a FreeBSD problem than an Ammonite problem in that case; can you reproduce via pgrep f bash without Ammonite at all?

Closing this to keep it out of the queue, but feel free to continue the discussion: I'll reopen if there's clearly work to do on the Ammonite side

[bbarker]

Looks like I lied - I was using tcsh, but it isn't an issue there:

[freebsd@debug ~]$ echo $SHELL
/bin/tcsh
[freebsd@debug ~]$ pgrep -f tcsh
40415
40034
14969

Cross-reference to FreeBSD bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215781

[bbarker]

As was pointed out be @jillest in the FreeBSD bug report, it is indeed not a bug, as the FreeBSD pgrep does not show ancestors by default (though it does with '-a'):

freebsd-freebsd@ %pgrep("-a", "java")
40084

freebsd-freebsd@ %pgrep("java")
ammonite.ops.InteractiveShelloutException
  ammonite.ops.Shellout$.executeInteractive(Shellout.scala:53)
  ammonite.ops.Shellout$.$anonfun$$percent$1(Shellout.scala:14)
  ammonite.ops.Shellout$.$anonfun$$percent$1$adapted(Shellout.scala:14)
  ammonite.ops.Command.applyDynamic(Shellout.scala:105)
  $sess.cmd11$.<init>(cmd11.sc:1)
  $sess.cmd11$.<clinit>(cmd11.sc:-1)

freebsd-freebsd@ %pgrep("init")
ammonite.ops.InteractiveShelloutException
  ammonite.ops.Shellout$.executeInteractive(Shellout.scala:53)
  ammonite.ops.Shellout$.$anonfun$$percent$1(Shellout.scala:14)
  ammonite.ops.Shellout$.$anonfun$$percent$1$adapted(Shellout.scala:14)
  ammonite.ops.Command.applyDynamic(Shellout.scala:105)
  $sess.cmd12$.<init>(cmd12.sc:1)
  $sess.cmd12$.<clinit>(cmd12.sc:-1)

freebsd-freebsd@ %pgrep("-a", "init")
1

To make things more fun, on Linux, pgrep -a means something totally unrelated; the Linux pgrep doesn't seem to support this kind of filtering (beside the point of this bug report).

[bbarker]

Aside: I thought OS X was closer to BSD, but I guess that is kernel space only perhaps.