🐧 Lunix



  • @Jarry said:

    it broke when the path was something like C:\\my super duper project

    On Unices, /home/jarry/foo/bar and ////home//jarry////foo////bar are equivalent, but doubled path delimiters have a special meaning at the beginning of Windows pathnames and are illegal inside them.



  • @tarunik said:

    Pipes are octet transports -- the only thing that has to happen is that the sender and receiver agree on the format.

    Right; but that's the problem, isn't it?

    With PowerShell, all tools written in it agree with the format. It's a known quantity. With Linux tools, there's basically no way to do it at all-- if you want to do some kind of image processing, you're stuck passing filenames around. And even with the list of filenames, there's absolutely no agreement in format.

    If you're seriously telling me you can pipe a sound clip around to different CLI tools (without passing around the file it's in), I'll need to see an example of it. Because I don't believe you can do that "easily", and I highly doubt it can be done at all.


  • ♿ (Parody)

    @blakeyrat said:

    And even with the list of filenames, there's absolutely no agreement in format.

    That's like saying there's no official way to get the user's "home"-ish directory on Windows because some programmers do it wrong.



  • This post is deleted!


  • @boomzilla said:

    That's like saying there's no official way to get the user's "home"-ish directory on Windows because some programmers do it wrong.

    Point me to the spec.


  • ♿ (Parody)

    @blakeyrat said:

    Point me to the spec.

    It's whatever the shell does to separate arguments. So the next guy gets a proper list of arguments. That's the "agreement." Sure, people do it wrong sometimes. That doesn't mean there's no right way, which is what you're effectively saying.



  • @blakeyrat said:

    If you're seriously telling me you can pipe a sound clip around to different CLI tools (without passing around the file it's in), I'll need to see an example of it. Because I don't believe you can do that "easily", and I highly doubt it can be done at all.

    Let's see if you understand this. CLI tools are made based on the assumption of working with a file path, not with a stream of data.

    APLAY(1)    General Commands Manual                                                                                   
    NAME
           arecord, aplay - command-line sound recorder and player for ALSA soundcard driver
    
    SYNOPSIS
           arecord [flags] [filename]
           aplay [flags] [filename [filename]] ...
    
    

    Another one:

    MPlayer(1)
    
    NAME
           mplayer  - movie player
           mencoder - movie encoder
    
    SYNOPSIS
           mplayer [options] [file|URL|playlist|-]
    

    Anyway, you can pipe streams of data

    NAME
           mkfifo - make FIFOs (named pipes)
    
    SYNOPSIS
           mkfifo [OPTION]... NAME...
    
    DESCRIPTION
           Create named pipes (FIFOs) with the given NAMEs.
    
    


  • @boomzilla said:

    It's whatever the shell does to separate arguments.

    Right; but we already know it can't handle filenames that begin in dash correctly. (A file named "-rm".) So if that's the spec, we already know it's buggy and wrong.

    @boomzilla said:

    That doesn't mean there's no right way, which is what you're effectively saying.

    It sounds to me like there is no right way. Your answer relies on the user just happening to know that leading dashes in filenames are dangerous and avoiding them.

    @Eldelshell said:

    Let's see if you understand this.

    Ok.

    @Eldelshell said:

    CLI tools are made based on the assumption of working with a file path, not with a stream of data.

    Right but that's not what I want. Say I have 4 seconds of audio I want to apply an echo effect to, ok? That's a pretty normal thing to do. So I have a CLI application "apply_echo_effect" and I want to pipe that 4 seconds of audio to it using some other CLI application.

    How do I do it?

    Unless I misread him, Tarunik just said a few posts up that an operation like this can be done "easily". I'm trying to get him to put his money where his mouth is.

    Even in my 1984 Macintosh, I could easily copy 4 seconds of arbitrary audio data from any audio-understanding application and paste it into another application to apply a filter to it or whatever. "Easily" here meaning "easily".



  • @blakeyrat said:

    If you're seriously telling me you can pipe a sound clip around to different CLI tools (without passing around the file it's in), I'll need to see an example of it. Because I don't believe you can do that "easily", and I highly doubt it can be done at all.

    $ aplay file.wav
    Playing WAVE 'file.wav' : Signed 32 bit Little Endian, Rate 11025 Hz, Stereo
    $ cat file.wav | aplay
    Playing WAVE 'stdin' : Signed 32 bit Little Endian, Rate 11025 Hz, Stereo

    In both cases, it played the noise.

    Now, obviously that's not a very useful pipe, but it would be totally possible to write some filter program that would transform a file on standard input, write it on standard input, and then put it into that pipeline as cat file.wav | transform | aplay. And it would be easy to write it -- you'd read from standard input and write to standard output exactly the same way as if you had a transform -o output-file.wav input-file.wav and were reading from input-file.wav and writing to output-file.wav. There's literally almost nothing extra that you'd have to support in order to do this.

    What's more, even if aplay didn't support reading from stdin (which I wasn't sure it would, but it did) you could still do it:

    $ aplay <(cat file.wav)                                                                            
    Playing WAVE '/proc/self/fd/11' : Signed 32 bit Little Endian, Rate 11025 Hz, Stereo
    

    and again, if I had a transformer I could say aplay <(cat file.wav | transform).

    And of course you could write a generate-sine program and say generate-sine 440 10sec | aplay too if you wanted, and you would write the same thing in generate-sine to standard output that you would to a file.

    (All of this would work on Windows too BTW if you have an analogue to aplay.)



  • @EvanED said:

    but it would be totally possible to write some filter program that would transform a file on standard input, write it on standard input, and then put it into that pipeline

    $ mkfifo foo && cat file.wav > foo ; aplay foo

    Or something like that, I can't test this right now because PulseAudio or Skype is killing my sound card :wtf:



  • @EvanED said:

    Now, obviously that's not a very useful pipe, but it would be totally possible to write some filter program that would transform a file on standard input, write it on standard input, and then put it into that pipeline as cat file.wav | transform | aplay. And it would be easy to write it -- you'd read from standard input and write to standard output exactly the same way as if you had a transform -o output-file.wav input-file.wav and were reading from input-file.wav and writing to output-file.wav. There's literally almost nothing extra that you'd have to support in order to do this.

    Ok; and if I want it to support every sound format and not just .wav?

    (Why the fuck would Linux be using .wav anyway? I guess they hate Microsoft's format less than they hate Apple's AIFF format? And God-forbid they use an actual open source format, like FLAC. Anyway...)

    I'd also like to point out none of the examples you've given here are even close to solving my original problem statement. And most of them are hypothetical.



  • @EvanED said:

    Like what do I want to do if I want to run foo bar? You can't just say foo bar, you can't just say foo(bar), or even run(foo, bar); the shortest thing I can think of is something like r("foo", "bar"). Now, granted my command names are short, but that's literally more than twice the length of what you could do with a normal shell.

    Got that case covered too!

    c.foo("bar")
    

    Where "c" is an object provided by the library (could stand for "command"). You can dynamically "assign" object properties in Python so this can be done.

    Still, that "drawback" was actually the point of what I had in mind. It was meant more as a way to replace complex bash scripts (of which there are loads in a standard Linux system) than as an interactive terminal.

    Explicitness might be annoying for interactive input, as you said, but for anything more complex than that it's a blessing. It's exactly the same case as with BBCode vs Markdown. Markdown is pretty and "hides" the code, but then you get obscure crap like ![alt text](https://www.domain.com/image.png "title text") for images. BBCode has [square][brackets][everywhere], yet its syntax is as simple and unambiguous as it can be.

    Similarly, sh is terse but then you get obscure syntax like while [ "x$VALUE" != "x" ], $# or ${#array[@]}.

    Other notes:

    • Most common commands would probably be replaced by built-in functions so you do not have to depend on external processes and can get and pass objects around rather than strings (which was kinda the point of this).
    • You could always create a Python-based language with modified syntax. Take Python implementation, change the parser a bit, new shell is all done. I was trying to avoid doing this so you wouldn't get as much backlash from the community.
    • No, I have not actually thought of this as a serious project, so don't ask me how I'd implement this or that because I don't know.


  • @blakeyrat said:

    If you're seriously telling me you can pipe a sound clip around to different CLI tools (without passing around the file it's in), I'll need to see an example of it. Because I don't believe you can do that "easily", and I highly doubt it can be done at all.

    Contrived example: cat test.mp3 | mplayer - (cat reads the mp3 and passes it to mplayer in a pipe.)

    If you want to make it a bit more interesting (but still contrived), here's using the same idea to send the mp3 across the network:

    • (host A): nc -l -p 12345 | tee bar.mp3 | mplayer -
    • (host B): cat foo.mp3 | nc (host A:s address) 12345

    (As a bonus, tee saves the received mp3 to the disk.)



  • @cvi said:

    Contrived example: cat test.mp3 | mplayer - (cat reads the mp3 and passes it to mplayer in a pipe.)

    Ok so you have one tool that does .wav and another that does .mp3. Why isn't audio just audio? The format doesn't matter; I just want my echo effect!



  • @blakeyrat said:

    Ok so you have one tool that does .wav and another that does .mp3. Why isn't audio just audio? The format doesn't matter; I just want my echo effect!

    Mplayer auto-detects the input's format (audio or video).



  • From an arbitrary 4-second clip sent as nothing but raw bytes? I find that very hard to believe.


  • FoxDev

    You are aware most binary formats have a header that describes the file, yes?

    Idiot 😛



  • @blakeyrat said:

    From an arbitrary 4-second clip sent as nothing but raw bytes? I find that very hard to believe.

    It will make a best guess, and maybe fail and give up, or possibly mis-detect the format if there's no additional meta-data (like a header at the beginning of the stream). Garbage in, garbage out.


  • ♿ (Parody)

    @blakeyrat said:

    Right; but we already know it can't handle filenames that begin in dash correctly.

    No, we don't. Well, I don't, and I think this falls into the realm of things you know that aren't so.

    @blakeyrat said:

    It sounds to me like there is no right way.

    Yes, we know that.



  • @blakeyrat said:

    Ok; and if I want it to support every sound format and not just .wav?

    The programs would have to support that of course (or you could have a decode-to-wav somefile.mp3 | transform-a-wav | encode-to-mp3 -o outfile.mp3 pipeline if if you have those tools). Linux can't magically solve that problem, just like Windows can't solve the problem of a program that doesn't understand all input formats.

    (Well, that's not quite true. Windows has an official bank of codecs which helps there, but Linux more or less has that too. And yes, command-line tools could use it.)

    But again, I reiterate: all of this is orthogonal to pipes. If you are working on a program that reads from a file and then writes to a file, then you could make it into a tool that works in a pipeline for almost no extra effort. The only thing you have to do is determine whether there is no filename specified and use stdin/stdout/etc. instead of fopen(...)ing a file. (Why is there no space between "of" and "fopen" @discoursebot?)

    @blakeyrat said:

    Why the fuck would Linux be using .wav anyway
    For crying out loud, I just did a quick search for an audio file. There are probably .oggs and others around somewhere. I'm not even sure that the wav file I grabbed is part of a typical Linux installation.

    @blakeyrat said:

    I'd also like to point out none of the examples you've given here are even close to solving my original problem statement
    ...so what was your original problem statement? Because near as I can tell it was "Now I want to pipe a sound sample" or "If you're seriously telling me you can pipe a sound clip around to different CLI tools (without passing around the file it's in)" which... I did.



  • @EvanED - Days Since Last Discourse Bug: -1



  • @RaceProUK said:

    You are aware most binary formats have a header that describes the file, yes?

    Right but we're not sending it a file, remember the scenario here? We're sending an arbitrary 4-second clip of audio from some audio file in some format. And since the only data that can be sent through a pipe is just a stream of bytes, that's how mplayer or whatever receives it.

    There's no way to take a stream of bytes from the middle of some audio file and interpret it correctly as an AIFF compared to an MP3 compared to a WAV. It can't be done.

    Idiot.


  • FoxDev

    Where did you get the 'clip from middle of file' garbage from? Those commands are sending the entire file through the pipe, including the file header.



  • @EvanED said:

    Linux can't magically solve that problem, just like Windows can't solve the problem of a program that doesn't understand all input formats.

    PowerShell solves exactly that problem. As did AppleScript/AppleEvents back in the early 90s, for that matter.

    @EvanED said:

    But again, I reiterate: all of this is orthogonal to pipes. If you are working on a program that reads from a file and then writes to a file, then you could make it into a tool that works in a pipeline for almost no extra effort.

    Right; but what I'm also slowly getting at is the whole concept of "a bunch of tiny tools piped together" is only useful if your data format is text. (Text including a list of filenames.)



  • @RaceProUK said:

    Where did you get the 'clip from middle of file' garbage from?

    THAT WAS MY ORIGINAL QUESTION YOU FUCKING RETARD! Go up and read the fucking thread. Fuck!


  • FoxDev

    So in your world, it's impossible to get a four-second clip from a file, wrap it in a new header, then send the result?


  • ♿ (Parody)

    @blakeyrat said:

    Right but we're not sending it a file, remember the scenario here? We're sending an arbitrary 4-second clip of audio from some audio file in some format. And since the only data that can be sent through a pipe is just a stream of bytes, that's how mplayer or whatever receives it.

    OK...so you would invoke it by saying what it was?

    @blakeyrat said:

    PowerShell solves exactly that problem.

    Huh? It magically adds features to my programs?

    @RaceProUK said:

    So in your world, it's impossible to get a four-second clip from a file, wrap it in a new header, then send the result?

    This is not unlike @cartman82 rejecting @tar's regex solution. :moving_goal_post:



  • @blakeyrat said:

    From an arbitrary 4-second clip sent as nothing but raw bytes? I find that very hard to believe.
    Ah, now there is a kernel of truth in this, which is that there is occasionally some format detection occurs based on the file name. The example I can think of off the top of my head is GCC, which determines what language to use based on the filename (e.g. .c is C, .cpp is C++, etc.). GCC will read from standard input, but you have to tell it what kind it is:

    $ cat hello.c | gcc -
    gcc: error: -E or -x required when input is from standard input
    $ cat hello.c | gcc -xc -
    $ ./a.exe
    Hello @Blakeyrat
    

    That's unfortunate, but it's also quite rare for something like that to arise; few tools detect the format from the file name.


  • Grade A Premium Asshole

    @blakeyrat said:

    Right; and what's stopping the Linux community from replicating that? What's their excuse for having such an old, stupid, clearly wrong system still?

    The most important thing for OS adoption and retention rate is not correctness necessarily, but stability. Even Windows has it. Look at all of the WTFery in System32. They have themselves had times when bugs were fixed, that broke programs, so they put the bugs back in (sort of) in order to preserve stability. If you go fucking with things, breaking shit for people, they will go somewhere else where it is more stable.

    So many people are using Bash scripts, that Bash is not going anywhere for a generation. Any changes better have one hell of a compatibility layer (as @Onyx said), or no one will use it at all. You can try to introduce another shell, but that has already been tried a few times with abysmal adoption rates.

    This is not a *nix problem either. It is a "people are creatures of habit" problem. I think Vim is arcane, so I use Nano when I need a CLI text editor, because I started really getting in to Linux late enough in the game that Nano is ubiquitous. Lots of people still use Vim though, because it is everywhere and that is what they know.

    Python 2.x is still more widely used that 3.x, because we are all resistant to change.

    PHP + Javascript is still used everywhere because lots of people learned that first and it is easy to get started on. It is also very easy to shoot yourself in the foot with, but it persists because of ubiquity and relative stability.

    Hell, even I am to blame for being a creature of habit. The build script for our most recent project is a .bat file. I could have written it in PowerShell, but I am familiar with CMD and I have lots of prior work to pull from.

    Adoption rates on lots of new, and arguably superior, technology remains low because we like the familiar. Bash is familiar. You can shoot yourself in the foot with any shell or technology. Those who use Bash know how to not do that already, so why should they change?



  • @RaceProUK said:

    So in your world, it's impossible to get a four-second clip from a file, wrap it in a new header, then send the result?

    I'm not saying it's impossible; I'm saying it doesn't exist. Nothing I've seen in this thread has convinced me otherwise.


  • FoxDev

    @boomzilla said:

    @RaceProUK said:
    So in your world, it's impossible to get a four-second clip from a file, wrap it in a new header, then send the result?

    This is not unlike @cartman82 rejecting @tar's regex solution. :moving_goal_post:

    Not sure I follow; if you're sending a sound clip, you're going to be sending a fully-formed and correct file, yes? If you're just sending the middle x bytes from a y-byte file, then of course it won't work. But if you're sending a 4-second audio clip chopped from a longer clip, the tool you use to do the clipping will produce a fully-formed clip (with correct file header) as output; that fully-formed file is then sent through the pipe.

    Actually, that works as a reply to @blakeyrat too.


  • Java Dev

    It's useful for self-descriptive data. If I take 64kb of data from the middle of an MP3 file you're going to need very specialized tools to get anything useful out of it, because I've probably thrown away a lot of information on how the sound in that 64kb was encoded.



  • @Polygeekery said:

    The most important thing for OS adoption and retention rate is not correctness necessarily, but stability.

    Right; Windows is FAR more stable, and also FAR more sensibly-designed.

    Again, you people are handing out metrics here that basically are convincing any reasonable person that Linux sucks ass.

    @Polygeekery said:

    This is not a *nix problem either. It is a "people are creatures of habit" problem.

    Being a creature of habit is still a problem.

    This is a "we're too fucking stupid to ever examine our own beliefs and also we like our system to be harsh and difficult so we can point and laugh at new users" problem.

    @Polygeekery said:

    Those who use Bash know how to not do that already, so why should they change?

    Because they and people like them are making computers into horrible monster machines that people hate.

    And I don't like that.

    I got into computers because computers were fun, you could play with them, mistakes were temporary and easily-corrected.

    Turns out only Classic Mac really ever was that way. The rest of the industry has been doing nothing but making things more difficult, less fun. Even Apple themselves, now.

    I hate it.



  • @PleegWat said:

    It's useful for self-descriptive data. If I take 64kb of data from the middle of an MP3 file you're going to need very specialized tools to get anything useful out of it, because I've probably thrown away a lot of information on how the sound in that 64kb was encoded.

    Wouldn't it be nice if the OS had a... hm... FORMAT for that data? A format that include information on how to interpret the raw bytes? And audio-using CLI applications could all just read/write to the same format? Wouldn't that be nice!

    Welcome to 1988 or so, BTW, when Mac Classic had this shit solved.


  • Java Dev

    @EvanED said:

    What's more, even if aplay didn't support reading from stdin (which I wasn't sure it would, but it did) you could still do it:

    $ aplay <(cat file.wav)                                                                            
    Playing WAVE '/proc/self/fd/11' : Signed 32 bit Little Endian, Rate 11025 Hz, Stereo
    

    and again, if I had a transformer I could say aplay <(cat file.wav | transform).

    You could probably also use

    cat file.wav | transform | aplay /dev/fd/1
    

    If that doesn't work, either the app handles stdin special, or it seeks on the input file or opens it multiple times and pipes won't work at all.


  • ♿ (Parody)

    @RaceProUK said:

    Not sure I follow; if you're sending a sound clip, you're going to be sending a fully-formed and correct file, yes?

    Apparently not, from what I get from what @blakeyrat is saying. It's not terribly clear, and possibly this is because I'm not an audio guy. But it seems like you'd have to tell the other program what you were sending somehow.

    I presume that's baked into the .NET blob you're sending over in a PS world. I'd imagine you'd supply a command line argument or something to the program in a bash world. But that doesn't seem to scratch whatever itch he's feeling here for some reason.

    I guess he's just upset that he can't send absolutely everything "in band" of the pipe. I suspect this is at least partly because he likes the self containment (which is a good thing) and/or he's imagining some long running process where you hand off lots of clips over time from one process to another (same one every time) instead of creating a new process with possibly different arguments depending on what you're doing.

    It sounds like someone claiming that you can't express something in a different natural language, then someone else saying, "Sure, you do it like this..." and then the first guy rejecting that because the grammars of the two languages don't match up and you had to form some sentences differently. i.e.: :moving_goal_post:



  • @Eldelshell said:

    Let's see if you understand this. CLI tools are made based on the assumption of working with a file path, not with a stream of data.

    How about this?

    $ cat ~/my_audio_file.wav > /dev/audio
    

  • Java Dev

    Hello rose-tinted glasses.

    I believe that in practice a lot of this goes via the gstreamer framework, and I do believe that has a standardized internal format. Though in that case your transform tool would probably be a gstreamer plugin, rather than a standalone binary.



  • It's just the frustrations of anybody coming from an OS that had this shit figured out in 1988 or so to "modern" OSes that still have trouble with it. Simple shit like copying a few seconds of video from VLC and pasting it into Vegas don't work. SIMPLE FUCKING SHIT. (Or course the irony there is that both Windows and Vegas support that scenario, it's VLC that's fucked.)

    And the point is, if you're promoting a system where you solve problems by piping together programs, those programs need a common format of the data so that can understand what the fuck they're supposed to be doing. You can't just have a stream of bytes, and come here telling me how great it is. No. That's not great. That's terrible. That's shit. You should be ashamed of that.


  • FoxDev

    @boomzilla said:

    @RaceProUK said:
    Not sure I follow; if you're sending a sound clip, you're going to be sending a fully-formed and correct file, yes?

    Apparently not, from what I get from what @blakeyrat is saying.

    Oh.

    Well, in that case, he's totally screwed. But then he'd be equally screwed, no matter the OS, CLI, GUI, BRI, or magic incantation environment you're using.
    @boomzilla said:

    It's not terribly clear, and possibly this is because I'm not an audio guy. But it seems like you'd have to tell the other program what you were sending somehow.

    Well, yes, otherwise how will the receiver know what to do with it? 😆
    @blakeyrat said:
    And the point is, if you're promoting a system where you solve problems by piping together programs, those programs need a common format of the data so that can understand what the fuck they're supposed to be doing.

    Isn't that what file formats are for? :trollface:



  • $ rm ~/\-rf
    


  • @blakeyrat said:

    @RaceProUK said:
    So in your world, it's impossible to get a four-second clip from a file, wrap it in a new header, then send the result?

    I'm not saying it's impossible; I'm saying it doesn't exist. Nothing I've seen in this thread has convinced me otherwise.

    Seriously?



  • @RaceProUK said:

    Well, in that case, he's totally screwed. But then he'd be equally screwed, no matter the OS, CLI, GUI, BRI, or magic incantation environment you're using.

    This shit all existed and worked at one point.


  • Java Dev

    @blakeyrat said:

    it's VLC that's fucked

    The VLC authors saw need to reinvent the wheel on practically the whole codec framework. This can be a blessing, with it handling file formats nothing else does. It can be a curse, in it not playing with anything else. Overall it is probably a :wtf:.

    Such applications exist in windows, they exist in linux, en they probably existed in your vaunted mac classic as well.



  • @PleegWat said:

    cat file.wav | transform | aplay /dev/fd/1

    If that doesn't work, either the app handles stdin special, or it seeks on the input file or opens it multiple times and pipes won't work at all.

    stdin is fd 0


  • Java Dev

    flag denied - not dickweedish enough.



  • In this situation, you have the fact that clipboard data is a set of (MIME type, stream of bytes). This is the case in Linux as well.



  • @riking said:

    In this situation, you have the fact that clipboard data is a set of (MIME type, stream of bytes). This is the case in Linux as well.

    Hahaha last time I tried Linux I couldn't even paste spreadsheet cells into a word processor without them getting converted into gibberish crap.

    Maybe it's better now. Maybe. But I was using it in like 2010 and they STILL didn't have their clipboard shit together.



  • Just wait for Wayland, then everyone will be speaking two protocols to the window manager 😛

    Related: Why isn't the file picker a DBus service yet?



  • @riking said:

    Just wait for Wayland, then everyone will be speaking two protocols to the window manager

    Will either of them actually work correctly?


Log in to reply