I was dismayed that the Linux user above expressed envy of
textutil on Mac OS X. Although I am on Mac OS X, I don't use
textutil. As far as I know, it is not capable of reading any formatting information from files anyway. I believe it just extracts text. There are many utilities for that purpose. For instance
antiword does it for pre-docx MSWord files and is cross platform.
catdoc, mentioned above, works better on some files. I'm sure I'm forgetting a few good ones ...
textutil, I use a shell script I inherited (I don't know who posted it originally or where) to decode
.docx files. Here it is:
unzip -p "$1" word/document.xml \
| sed -e 's/<\/w:p>/\
/g' -e 's/<[^>]*>//g'
I named it
docx, put it in
/usr/local/bin and said
sudo chmod 700 docx to make it executable. Then I say
docx mystupidlittlewordfile.docx | less
to read the contents of any
.docx file quickly and conveniently.
All it does is three things one per line (not counting the first line that tells which shell to use). First, it unzips the xml document containing text. This xml document is currently usually
word/document.xml in the
.docx file which, if you have not guessed, is a structured
.zip file. If this script does not work, the first thing I do is to say
unzip -l mystupidwordfile.docx
so I can see where the text is. You should look inside
word/document.xml anyway, to understand the next two lines of the shell script above. The second line pipes the output to a
sed script that replaces MSWord's symbol for newline with an actual newline. The third line pipes this output to another
sed script that sends everything to
stdout except whatever is between angle brackets.
There are actually a number of other useful items between angle brackets, such as table layouts, that would be easy to add with intermediate
sed scripts. You could replace many of these useful items, for instance, with
markdown equivalents. I just haven't gotten around to it. The main reason I use this script is so that I can see the content of an average
.docx file on a network volume to see if I can understand its content without having to run MSWord to read it. Nine out of ten times, this is all I need to read and understand
.docx files. Formatting in average
.docx files is usually decorative rather than meaningful.
Presumably, Microsoft will change these angle bracket directives with successive versions of MSWord to make it harder to use any non-Microsoft tools on them. I have heard that Microsoft's original attempt at an open format was essentially a MSWord document surrounded by angle brackets.
Nevertheless, as long as public pressure remains for them to use XML, at least some of the directives can be read and modified from version to version. My view is that the end user should be able to modify the tool when it fails because intentional incompatibility has been introduced by the monopolist. I'm not sure how to do that. My solution requires that the user know
sed and regular expressions and be less lazy than, evidently, I am. This will only fit a small subset of people who would like, perhaps for ethical reasons, to avoid owning a copy of MSWord.