I can run this command:

$ play mylist.m3u

And music plays.

I can then press Ctrl-Z to suspend the job, and issue bg to have it run in the background.

However, if I then run disown and exit, the music stops playing, even though the play command still shows up in ps.

I would expect the music to keep playing.

Also interesting

I run the command

$ play mylist.m3u &

Music does not play. The job shows as the stopped status.

I can also run the command

$ nohup play mylist.m3u &

And no music plays - the job immediately stops.


$ nohup play mylist.m3u

Does have music play, but I can't disown it, as before.

It seems like all these are related.

Most programs behave well when disowned or run through nohup, but not SoX.

Does anyone know why?

  • If you want to play music as server, use mpd and ncmpc/mpc...
    – jirib
    May 31, 2012 at 9:02
  • @JiriXichtkniha: Thanks - I already run xmms2, so it's no problem. I am more just curious why this fails. I want to know what is special about SoX that causes this odd behavior.
    – jwd
    May 31, 2012 at 14:17

3 Answers 3


For the rare person who, like me, both had this problem and finally managed to google for something that wasn't about baseball* and want an actual solution:

$ play whatever.wav &>/dev/null </dev/null &

That runs in the background without stopping.

* The Red Sox of Boston play baseball, and apparently some players prefer the limelight to the background. Grumble.

  • Cool! I am curious - why are there two &? I'm unfamiliar with that syntax.
    – jwd
    Oct 10, 2012 at 16:38
  • 1
    "&>/dev/null" means "Redirect both stdout and stderr to /dev/null." It's analogous to ">/dev/null 2>&1". The second ampersand just puts the job in the background in the usual way.
    – tex
    Oct 18, 2012 at 14:00

SoX wants/needs input & output... by typing 'play xxxx' in the console, you're running it normally, with stdin & stdout (& stderr) all connected.

When you background the job (with &), it starts, then is paused since it's waiting for access to stdin & stdout.

Same thing occurs when you 'nohup' a job. If it needs keyboard input, it'll "block", and get paused by the system until it receives access to stdin.

disown'ing a process effectively cuts it off from stdin & stdout which were connected to the console which started the process.

It's still "running", but is blocked (paused) by the system since it's waiting for access to stdin & stdout.

  • Do you know why it successfully runs in 'bg' mode, while the controlling terminal still exists? Is stdin still active in that mode, just nothing sent to it?
    – jwd
    Jul 6, 2012 at 14:50
  • That'd be my best guess. Depends on the program and how it handles its input & output too.
    – lornix
    Jul 6, 2012 at 14:58

It's also possible to use the -q option to make sure SoX doesn't write to std-whatever, without redirecting to /dev/null.

$ play filename -q &
  • I don’t know why your answer is at 0, maybe it wasn’t the case back then but I was also wondering why sox was stopping to play when pur in the background. After reading the first answer with the redirection to /dev/null hack I read yours and wondered if it was not an appropriate response or the cleverest one. I’m glad I tested! ^^ $ sox -q catapult_attack2.wav -t alsa default tempo 4 gain .5 pad .7 repeat 10 & sox -q catapult_attack2.wav -t alsa default tempo 8 gain .5 pad .35 repeat 20 &
    – Stéphane
    Jan 3 at 19:27
  • I just dived into sox a few days ago. The reason for doing so has been totally fulfilled a long time ago, but I can’t resist the urge to play with this wonderful software. The subject of this question is the first thing that seems to be wrong to me. The quiet mode, with no output to stdout, shouldn’t be the default behavior? I know I can make an alias, but still, I wonder why.
    – Stéphane
    Jan 3 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .