Make logging related options consistent amongst themselves

[ghost]

A bit of path chaos here

-w takes a relative path from where the script was launched
-p does not seem to do anything ( always just seems to default ) ?
-l -o -e do what i expect sort of
and the last bit of the command
i saw was a bug sort of but from what every one said to just place the full path and that some people use it to kill multiple similar named scripts!?!?!?!
What wait I want to do some of that what the hell are you guys programming your mad men.

forever start -w ./app.js -p `pwd`/forever -l `pwd`/forever/log -o \
  `pwd`/forever/OUT -e `pwd`/forever/ERR `pwd`/app.js

[indexzero]

Thanks. I'm going to mark this as a 1.0.0 thing to make consistent.

[markstos]

I'll also note that the -l command doesn't document precisely which log output it handles. It's not explicit that in addition to the forever-specific laws it also includes the STDOUT and STDERR of the child process.

[adamreisnz]

Just want to make sure that #373 is captured here fully. I think it's important to not have logging turned on by default unless explicitly specified. This will prevent buildup of GB's of log files that the user is not aware of.

Also, it would remove the need to mess around with /dev/null or NUL (on windows) to stop forever from writing logs. Because as of now, I don't see a way to specify either /dev/null or NUL depending on what environment you're on, so there's no way to distribute an app with a forever.json which will work as intended on both windows and linux/mac.

[markstos]

I think it's important to not have logging turned on by default unless explicitly specified. This will prevent buildup of GB's of log files that the user is not aware of.

But not having logging can create a buildup of bugs or security issues that the user is not aware of because there are no logs for the app to communicate back to the user about!

Logging to STDOUT is a good idea and doesn't take up any disk space (unless your redirect it). I provide more justification for logging to STDOUT over on this log rotation bug.

Assuming you using a modern Linux distribution, it's probably already running systemd, which is excellent at process supervision, including handling logging. For example, it cleanly handles apps that log to STDOUT and allows you to store the logs in memory or on disk as you prefer, with a maximum amount of disk (or memory) space used for logs. You can skip the forever.js layer and eliminate another moving part from your system. See also: Running Node.js on Linux with systemd.

[adamreisnz]

I think people that use forever for production apps are smart enough to know that they should capture errors. Most probably use external cloud solutions like LogDNA and/or Sentry to capture logs and errors anyway.

For a cli tool to assume that we don't know what we're doing and write logs by default to a random hidden folder (I think it defaults to ~/.forever) just seems slightly abusive to me.

Logging to STDOUT by default should be fine, but forever runs in the background so not sure how that would work.

Thanks for your systemd suggestion, but I actually require forever to run a node app on a windows machine (it hooks up to some archaic hardware). The app itself logs quite a lot to stdout, and I don't want that cluttering up the hard disk space on the machine, which is limited as it is a laptop with only 32GB SSD.