/dev/chat

12:33 PM

I found most of audio & video formats are supported on Trisquel. But in case of Ubuntu, it recommends to install ubuntu-restricted-extras. As Trisquel is completely free-software distribution there must free packages pre-installed that support most video & audio formats. I want to get list of that free packages (Say replacement for ubuntu-restricted-extras).

Braiam

1:02 PM

@Pandya anything not in restricted repository is considered free

@Braiam mp3 and other common audio & video formats are not supported without ubuntu-restricted-extras on Ubuntu. I want to know Which is free replacement/alternative to it?

Braiam

@Pandya there's none

@Braiam As I said Trisquel supports common video & audio formats with only free-software So, I want to get list of that required package(s) that are pre-installed with Trisquel.

Braiam

@Pandya aren't you using Trisquel right now? why don't just ask the system?

1:26 PM

@Braiam yes I am running Trisquel right now. can you help me how to find/list those packages?

casey

2:23 PM

@Pandya you'll find that for av codecs there are no free alternatives for some of them

2 hours later…

4:51 PM

@derobert see my updated answer. Is that what you meant? Can't it be done better?

@terdon Yeah. You can use that mode instead of parsing the column-based output.

@derobert There doesn't seem to be an easy way of getting both the PID and the access mode on the same line though.

Same line, no. It's intended for parsing. You'd have to use read in the shell.

And I did try reading the man page but it's really scary. I understand less than half of it. I know very little about such low-level stuff.

The lsof manpage is indeed confusing.

4:55 PM

It seems weird that they have an option for null-separated fields but that just prints each field on a separate line ending with \0\n. That does not make for easy parsing.

I have no idea where they came up with that format...

... actually, I bet it makes it easier with line-buffered reads.

Its easy enough to parse in C, or Perl, or...

Just not with grep!

casey

Yea, \0\n will be friendly for c style strings (anythin null terminated) and line buffered reads

anthony@Zia:~$ lsof -p 26798 -a -d 0-999 -F fptDian
p26798
f0
ar
tFIFO
D0x9
i58145651
npipe
f1
au
tCHR
D0xc
i35
n/dev/pts/32
f2
au
tCHR
D0xc
i35
n/dev/pts/32
f9
au
tunix
i26740
nsocket

you read that line by line, pid 26798, fd 0, access read, file type FIFO, device 0x9, inode 58155651, name pipe.

Yeah but since most parsing tools deal with lines, it would have been far simpler to print null separated fields on the same line.

put a 0 on the end:

$ lsof -p 26798 -a -d 0-999 -F fptDian0 | xxd
00000000: 7032 3637 3938 000a 6630 0061 7200 7446  p26798..f0.ar.tF
00000010: 4946 4f00 4430 7839 0069 3538 3134 3536  IFO.D0x9.i581456
00000020: 3531 006e 7069 7065 000a 6631 0061 7500  51.npipe..f1.au.
00000030: 7443 4852 0044 3078 6300 6933 3500 6e2f  tCHR.D0xc.i35.n/
00000040: 6465 762f 7074 732f 3332 000a 6632 0061  dev/pts/32..f2.a
00000050: 7500 7443 4852 0044 3078 6300 6933 3500  u.tCHR.D0xc.i35.
00000060: 6e2f 6465 762f 7074 732f 3332 000a 6639  n/dev/pts/32..f9

doesn't get the pid on the same line, but does get each fd, apparently.