@agitato816 said:

Additional Question:

[shell] object with AWK and Perl script also run under Windows or other OS?

No. [shell] just invokes the Linux shell separately installed in the Linux host that Pd is running in. The Linux shell is able to run awk, perl, or whatever else is installed on that host that the Pd user has permissions to run. None of them except [shell] itself is part of Pd. So if you don't have the separate awk, perl or whatever you call by passing to [shell] both installed and accessible by the Pd user, it's not going to work. Which is the case on any other OS other than Linux. Unless they do have awk or perl etc installed separately, which I believe MacOS does have (Windows doesn't by default have awk or perl, but it might be possible to install some version of them that [shell] can invoke). Some functions, like ls , are builtin shell functions, so [shell] has them builtin too.

You can check which actual shell Pd invokes by using
[echo $SHELL]
|
[shell]
|
[print]

@Matthew said:

That won't actually work, since each multiword line from [shell] is a list itself; shell is outputting a list of lists, from which list #n is desired. There is no list of lists (of symbols) native in Pd.

For something called "pure data", Pd has very crude and limited data structures. Especially if the data isn't numeric.

Maybe PDContainer, like some use of [h_multiset data] receiving the shell output, like: [ls -al]-[shell]-[h_multiset data] .

why would "casting" as a list not work? the reason it's there is to put the list selector on in order to get the right element (the 5th) from $5 because pd recognizes the list selector.
the reason the error occurs is in the case when the fifth element isn't present, which some

logic would fix.
otherwise it works, but i'm still curious why it wouldn't?

@sebfumaster said:

@Matthew said:

That won't actually work, since each multiword line from [shell] is a list itself; shell is outputting a list of lists, from which list #n is desired. There is no list of lists (of symbols) native in Pd.

why would "casting" as a list not work? the reason it's there is to put the list selector on in order to get the right element (the 5th) from $5 because pd recognizes the list selector.
the reason the error occurs is in the case when the fifth element isn't present, which some

logic would fix.
otherwise it works, but i'm still curious why it wouldn't?
Did you run it? Your patch doesn't work because [ls -al( returns a series of lines, each line a series of words. Pd doesn't recognize the newline delimiter, only the space delimiter that makes the whole output look like just one long list, that happens to contain lines. There's no structure in Pd to say "5th line" or "fifth list", just "5th atom in a list" at best.

Pd doesn't have data structures at all except for space-delimited list, whether of symbols or other atoms. It doesn't even have strings. It doesn't have any way to make more complex data structures, except the crazily complicated struct/template system that doesn't support runtime dynamic template construction, except perhaps by the ridiculous kluges for dynamic patching. Pd is a programming system, but it is not really a *metaprogramming* system, where runtime logic can change definitions. It's an object system with classes available for instantiation only by the programmer, not by the program.

That's why it's a pretty interesting music/performance system, but an extremely frustrating general programming system. Instead of "Pure-Data" it really could be called "No-Metadata".

I ran it (well, with ls -a -l), it worked. agitato was asking for the 5th item in each list i think. shell outputs the lines as seperate messages.

@sebfumaster said:

I ran it (well, with ls -a -l), it worked. agitato was asking for the 5th item in each list i think. shell outputs the lines as seperate messages.

I ran the attached patch and got first the "$5: argument number out of range" error agitato reported, then a series of "print: <float>" lines where <float> was a number, mostly 4096. I got several sets of those, probably one for each file in the directory being listed. What do you get?

http://www.pdpatchrepo.info/hurleur/ls-shell-test.pd

it seems like shell sometimes splits lines for no reason? but again, other than that it seems like this list of floats is what agitato was trying to get. and as I mentioned when ls outputs the total on the first line some simple

or [once] logic would fix the error, though I'm not sure why [shell] splits some lines and not others.

@sebfumaster said:

but again, other than that it seems like this list of floats is what agitato was trying to get.

Ah, the 4096 values the patch prints are indeed the directory sizes, and are what agitato was looking for. The [shell] docs didn't indicate it output line by line, just that it bangs the right outlet when complete. Yes, it does have some bug where it splits some lines, and it looks like it sends a 0, not a bang, to the right outlet when complete.

So your patch is the correct answer, and your [$n( filter on [shell] output is a good technique. How would you alter the test patch I attached earlier to pull just, say, the 3rd line output from [shell]? Or better yet, the xth line, as specified dynamically by the patch during runtime?

seems like theres more than 1 bug: this works for me sometimes but sometimes does nothing but output 0 from the right. I was also noticing this when I was testing the above as well. but if shell worked this patch would I think

http://www.pdpatchrepo.info/hurleur/ls-shell-test.pd