I've added the inspect() method to the output of other commands including grep, and unified their output result (now all are arrays, not strings separated by endlines). I'll add support for the -l parameter en ls to show how flexible can this be.

@ariporad what are your thoughts? I like the idea of having grep() and sed() returns lists similarly to how ls() does (it seems more useful to me). The output on the node commandline isn't as important to me, and I think it might actually be confusing to display something other than what is returned.

@piranna the colors definitely rock though! The only significant one missing from ls() is green for executables, I think.

@piranna would you be interested in refactoring this into several smaller PRs? I think ls -l, for example, would benefit users, and we could merge that much sooner than the whole chunk.

Yeah. I'm not sure about the inspect bit... It could be confusing to some people.

@piranna: I'm not really sure about the inspect() thing, I feel like it's a little counter-intuitive.

@nfischer: I personally vote to close this. What do you think?

@ariporad I don't think we can merge this as-is, because it implements too many things.

@piranna I'd really like to merge some of these features, but I would need them to be done in separate PRs. If you or anyone else would like to refactor some of these features into separate PRs, that would be very appreciated.

The output on the node commandline isn't as important to me, and I think it might actually be confusing to display something other than what is returned.

When used on interactive REPL it matters, specially with the -l flag.

@piranna the colors definitely rock though! The only significant one missing from ls() is green for executables, I think.

Colors come from the $LS_COLORS environment variable, so they are the ones defined on the system, I can't do here nothing.

@piranna would you be interested in refactoring this into several smaller PRs? I think ls -l, for example, would benefit users, and we could merge that much sooner than the whole chunk.

I started Coreutils.js, my own implementation on the Unix commands using streams of objects instead of arrays. I think this is fairly a better approach to that problem.

@piranna I'd really like to merge some of these features, but I would need them to be done in separate PRs. If you or anyone else would like to refactor some of these features into separate PRs, that would be very appreciated.

You can cherry pick the parts you are interested about, but definitely I think inspect() support is a plus, if not it would not be used on the Node.js core libraries... One thing is how are the data internally, and how it's represented, and an example of this is the -l flag that's only purposse are visual artifacts.

@ariporad I vote to put off adding inspect(), and focus on the underlying details, like ls -l, and turning multi-line output into arrays where it makes sense.

@nfischer: SGTM.

@nfischer: I vote we close this pull request, because it's really tied to the current ls implementation, which is about to be replaced.

SGTM