8

Using bash on Mac OS to edit some man pages for my own use.

In Mac OS the command open -t filename will open the specified file in the system's default text editor. 

$ man somepage | col -b

will properly render the designated man page. What I want to do is open the rendered man page in the text editor. I can accomplish this as follows: 

man somepage | col -b > filename && open -t filename

I should probably be happy with that, but I got it in my brain that there must be a "better way" to do this using only piping and redirect. Also, the command above tends to "litter" my file system with files that I may not need to retain - and therefore requires another step to delete the cruft. Ideally, I could open the rendered man page in the editor without a file name, or some generic filename that would be overwritten on each invocation. I've spent about an hour now noodling over this, trying different things, to no avail.

What made most sense to me was this: 

$ open -t < man somepage | col -b

or this: 

$ open -t &1 < man somepage | col -b

but of course that doesn't work because the shell takes man as the filename. Am I even close to getting this right? Am I daft for trying?

Improve this question

1 Answer 1

Reset to default
7

You can pass open the -f flag to have it read the contents from stdin and open them in the text editor, which makes it usable in a pipeline.

So something like this should do what you want:

man somepage | col -b | open -tf

See also:

Improve this answer
7
  • 3
    I'd add that the thing Seamus was dancing around was process substitution open -t <(man somepage | col -b), but that doesn't actually work because of the way both open and TextEdit behave.
    – Michael Homer
    Sep 3, 2018 at 4:39
  • @MichaelHomer: Yes, but it was a dance poorly executed! I'm intrigued by your statement though: "that doesn't actually work because of the way both open and TextEdit behave". Can you expand on that?; i.e. how does one know what constitutes "proper process substitution behavior"?
    – Seamus
    Sep 3, 2018 at 16:28
  • 1
    The scales have fallen from my eyes :) Oddly, I studied man open intently while trying to get this to work, but glossed over this (-f option) probably 5 times... as Obi-Wan said, "We see what we want to see..." OWTTE
    – Seamus
    Sep 3, 2018 at 16:34
  • 1
    @Seamus @MichaelHomer: the reason why process substitution (open -t <(...)) doesn't work here is the same as in this answer to Why does BASH process substitution not work with some commands?. In short, the editor would get a /dev/fd/N that looks like a file but it's in fact a pipe. Editors (even if they're happy taking piped input from stdin) are not always happy with piping through process substitution fds.
    – filbranden
    Sep 3, 2018 at 16:53
  • 2
    @Seamus On top of what Filipe says, open doesn’t actually start the program as a child, it asks the operating system to spawn it and terminates. There’s no relationship between the two processes to preserve the file descriptors; once open terminates so does the pipeline, and nothing has a chance to see the contents first. TextEdit only accepts regular files, but even if you have a different default editor that is happy with the file name it won’t help still because it will never get the chance to use it.
    – Michael Homer
    Sep 3, 2018 at 18:54

You must log in to answer this question.

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