job kill should take multiple arguments, and where is foreground and wait?

[xpusostomos]

Basics

• I have done a basic search through the issue tracker to find similar or related issues.
• I have made myself familiar with the available features of Nushell for the particular area this enhancement request touches.

Related problem

The UNIX way has always been that commands generally take unlimited arguments. That's how it is with bash's kill. Plus I want to be able to do something like...

job kill ...(job list | get id | echo $in)

which I can't do now because job kill only takes one argument.

As another point, I'm super confused about nushell job control. job unfreeze says it puts a frozen job into the foreground, so how do I unfreeze a frozen job into the background? Aka the bash "bg" command? it's not spawn, that creates a new process, not unfreezing an existing one. It doesn't seem to be an option, which makes the whole system very bizarre in my mind. nushell seems confused about whether it wants to adopt unixy terminology, or to flagrently disregard it. Why is it unfreeze and not "foreground"? Why isn't there a "job background" ?

Speaking of missing features, where is "job wait" command ? Wait is also one of the core shell job control commands that is also missing.

It remains odd to me that nushell "hijacks" common unix commands like ps, find, echo etc... which it also does for kill, as a nushell builtin... but kill doesn't take job ids, only pids. so we also have job kill But we don't have wait, or job wait. Would it be so terrible if kill took jobspecs like kill %1 like every job control shell since BSD invented it?

job is handicapped compared to bash's "jobs" which can list only running or stopped jobs with options.

It seems to me that every shell that ever had job control, starting from csh, has always had the kill, wait, bg, fg, jobs, set of controls for a good reason, and nushell has gratuitously given up that for a confusing situation of kill vs job kill.

Lack of ability to background with something close to the simplicity of "&" is a real deal killer. And without "wait" there's a whole raft of things that are impossible. It's not like wait is hard to implement or something.

Describe the solution you'd like

• job kill take multiple arguments
• job background command
• job wait command
• ideally more UNIXy way of doing it, aka "&", fg, bg, jobs, wait, kill taking job specs

Describe alternatives you've considered

I don't know of any way to wait if it's not builtin.

Additional context and details

No response

[fdncred]

This is opensource. You should feel free to contribute and submit a PR for anything. Just make sure to follow the contribution.md and that your PR is cross-platform so that it works on Linux, MacOS, and Windows at a minimum. This is what makes it more difficult.

[xpusostomos]

@fdncred Thankyou captain obvious for giving me permission to fix it. As a non-rust programmer, I try to use my talents where they are best directed. I do note however that cygwin's C library simulates Unix job control on Windows so perfectly that bash job control works, so that's not the most compelling argument I heard. And simply having commands allow multiple arguments is not hard.

[fdncred]

Being unix and posix compliant has always been a non-goal for nushell. So, your arguments aren't well received in that regard. However, I agree that augmenting our limited job control functionality with some of these features would be cool. All it takes is someone with the passion and the know how to implement it. Issues with a bunch of opinions don't really make for good issues though since everyone has an opinion and it really has nothing to do with how nushell works, just how you think it should.

[xpusostomos]

@fdncred what do you mean posix compliance, you mean posix shell? Clearly it's not attempting that. But job control came from BSD unix. Windows never had it or anything like it. The job control primitives that came from csh were perfectly designed to implement the concept of job control. Reinvent that wheel at your peril.

But nu does appear to be trying to be a unix-ish shell.... when you have bunch of built-in commands called ps, which, kill, cp, du, ls, that wasn't inspired by windows. And if it's going to be a useful shell on unix, it has to be at least as good as posix shell, and not leave posix shell programmers saying wtf is this. It needs to be able to fully exploit the OS's inherent features.

I'm tempted now to have a whine that "find" gratuitously interferes with the unix command of the same name but which does something completely different. Heck, FIND on windows is closer to what the Unix find does, and it gratuitously overrides that too.

[fdncred]

Nushell takes inspiration from a variety of things but nushell has never set out to be a posix shell. So, your bash scripts won't run in nushell. Nushell cares very little about the brevity of bash. You're welcome to your opinions but they don't count for much here, especially with your rude and insulting tone. If you read the documentation, you'll learn that you can escape the system with ^ so ^find will run the external command. I assume you know that, but your whine doesn't seem to indicate it.

[xpusostomos]

Pick a lane.. you don't like brevity, why do we have ls, ps, cp builtins? I challenge you to think of a coherent reason, then apply that reason to why find is overridden. I'm perfectly aware of ^, but the shell's purpose in life is at least 50% to be running Unix commands, and when you gratuitously override standard unix commands with commands that aren't even roughly equivalent, you just defeated your own purpose for being.

Not being overly concerned with brevity is one thing. But making me type vi ...(which blah | get path | echo $in) instead of vi $(which blah) because you gratuitously overrode which is something else. bash figured it out, have type blah for verbosity, and which blah for commands. If you're going to override a unix command, at least have it somewhat a replacement. Or if you don't care about brevity, just have the posix command namespace completely off limits and implement dir, processes and copy in place of ls, ps and cp.

[fdncred]

You can create aliases to the commands you prefer that are external to nushell. If you don't like our choices, you don't have to use nushell. Things in nushell can be changed when approached in a respectful manner but you chose to do the opposite with your opinions.

It's issues like this that may opensource so difficult. One zealot ruins it because the software doesn't work the way they think it should and they think their opinion is the only one that matters regardless of the 600+ contributors who came before them.

Nushell is not perfect and I agree with some of the statements in this issue, but the approach was all wrong. Let it be an example of how not to approach the nushell core-team.

You can't please everyone. Good luck.