Question of setting environment variables
Chris Saunders
things. If I recall correctly, there use to be a file in my home directory
called .bashrc or maybe .bash_profile in which one could set environment
variables. I don't see this file and would like to add some environment
variables.
Sidney Lambe
Just create it. I have ~/.profile, also, which contains only this:
if [ -f ~/.bashrc ] ; then . ~/.bashrc ; fi
Both files have these permissions:
-rw-r--r--
You will probably want to export the variables:
export FOO_OOF=foofoo
If you want them to apply to the entire system, use /etc/profile.
Sid
--
My newsfilter kills all threads and subthreads
originating with a post from googlegroups.
See: http://tinyurl.com/4v394u
Glyn Millington
http://www.slackbook.org/html/book.html#SHELL-BASH
Its good stuff!
atb
Glyn
--
RTFM http://www.tldp.org/index.html
GAFC http://slackbook.org/ The Official Source :-)
STFW http://groups.google.com/groups?hl=en&group=alt.os.linux.slackware
JFGI http://jfgi.us/
Glyn Millington
Sorry - that wasn't the best link to give you!
Try this one :-
http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_01.html
~kurt
>
> Just create it. I have ~/.profile, also, which contains only this:
>
> if [ -f ~/.bashrc ] ; then . ~/.bashrc ; fi
>
"man bash" also has a surprising amount of information.
- Kurt
Dan C
<understatement of the year>
> "man bash" also has a surprising amount of information.
</understatement of the year>
Heh. Is there a longer man-page known to man?
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
The Usenet Improvement Project: http://improve-usenet.org
Glyn Millington
> On Wed, 24 Sep 2008 21:07:21 -0500, ~kurt wrote:
>
> <understatement of the year>
>
>> "man bash" also has a surprising amount of information.
>
> </understatement of the year>
>
> Heh. Is there a longer man-page known to man?
Nice one!
$man bash | less -N gives 4902 here
$man fvwm | less -N gives 8899
any advance on fvwm?
Beej Jorgensen
>$man bash | less -N gives 4902 here
>$man fvwm | less -N gives 8899
$ man gcc | wc -l
11542
But I think this is the record:
$ man perltoc | wc -l
12602
-Beej
tTh
>
> "man bash" also has a surprising amount of information.
Don't do that if you have only ten minuts of spare time.
--
No sig available.
tTh
> $man fvwm | less -N gives 8899
>
> any advance on fvwm?
Mmmmm. thinking...
Oh, I've got it.
fvwm --> f*ck*ng very wide manpage ?
--
No sig available.
Mark Madsen
> $man fvwm | less -N gives 8899
That would be about 99 lines on using fvwm and about 8800 lines on its
config file syntax?
Glyn Millington
Pretty much! But there is more .........
* fvwm
* fvwm
* FvwmAnimate
* FvwmAuto
* FvwmBacker
* FvwmBanner
* FvwmButtons
* FvwmCommand
* FvwmConsole
* FvwmConsoleC.pl
* FvwmCpp
* FvwmDebug
* FvwmDragWell
* FvwmEvent
* FvwmForm
* FvwmGtk
* FvwmGtkDebug
* FvwmIconBox
* FvwmIconMan
* FvwmIdent
* FvwmM4
* FvwmPager
* FvwmPerl
* FvwmProxy
* FvwmRearrange
* FvwmSave
* FvwmSaveDesk
* FvwmScript
* FvwmScroll
* FvwmTabs
* FvwmTaskBar
* FvwmTheme
* FvwmWharf
* FvwmWinList
* FvwmWindowMenu
* fvwm-bug
* fvwm-config
* fvwm-convert-2.2
* fvwm-convert-2.4
* fvwm-convert-2.6
* fvwm-menu-desktop
* fvwm-menu-directory
* fvwm-menu-headlines
* fvwm-menu-xlock
* fvwm-perllib
* fvwm-root
:-)
fuzzix
> $ man gcc | wc -l
> 11542
>
> But I think this is the record:
>
> $ man perltoc | wc -l
> 12602
$ man wireshark-filter | wc -l
197775
OK, it's not included by default...
Keith Keller
If by "surprising" you mean "difficult to navigate", I agree.
Look up the INVOCATION section of the manpage for bash. It has docs for
what files are sourced on startup. You'll see that there might be good
reason not to do what ''Sidney'' aka netkook Alan Connor suggests above.
(In particular if you use interactive shells that might not be login
shells you do not want to call .bashrc from .bash_profile or vice versa.
Most people don't do this, but some do.)
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Beej Jorgensen
Good Lord, man... that's impressive.
-Beej
Rupa Zangpo
>> "man bash" also has a surprising amount of information.
>
> If by "surprising" you mean "difficult to navigate", I agree.
>
> Look up the INVOCATION section of the manpage for bash.
No, no, no, NO! If you've got something to do with GNU Software, look up
the *info*-pages! 'info bash' is the way to go. There are no manpages
about GNU Software except the ones someone put together unofficially.
Rupa
Mike
Hey! Yeah! Another obscure method of storing and retrieving information!
Just what the world needs!
What, I have to wonder, is the problem with html? Its universal, simple,
and all but one single wood burning computer somewhere up a mountain in
Siberia actually has the capacity to read html from the moment they are
booted.
So why are we still stuck with "man this" and "info that" and "xyz the
other" etc.? Why are these obscure, specialist, restrictive,
incantational, and arguably obsolete ways of storing information still
with us?
Ah mean tah say! Plain text is as searchable as a man/info page!
--
*===( http://principiadiscordia.com/
*===( http://www.badphorm.co.uk/
*===( http://www.zenwalk.org/
Sylvain Robitaille
> No, no, no, NO! If you've got something to do with GNU Software, look
> up the *info*-pages! 'info bash' is the way to go. There are no
> manpages about GNU Software except the ones someone put together
> unofficially.
That's the problem with GNU: they had to go and re-invent documentation
too.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Sylvain Robitaille
> What, I have to wonder, is the problem with html?
That's the problem with newbies: they want everything to be a web page
...
> Its universal, simple, and all but one single wood burning computer
> somewhere up a mountain in Siberia actually has the capacity to read
> html from the moment they are booted.
Perhaps, but even that one computer in Siberia is able to process
and display a manpage relatively quickly, so "man" is still the most
universal.
Do you have an html reader that will search for a particular file,
through a preset search-path, based on arguments you give it? See
"man man" for details.
> Ah mean tah say! Plain text is as searchable as a man/info page!
Um ... a manpage *is* plain text, with some markup (sound familiar?)
I would be very surprised if the same were not true of info pages,
but I care too little about those to bother checking.
In fact, check out the man2html manpage (that would be "man man2html", of
course ;-). I think you you'll find you *can* have your manpages in html.
Joost Kremers
> So why are we still stuck with "man this" and "info that" and "xyz the
> other" etc.? Why are these obscure, specialist, restrictive,
> incantational, and arguably obsolete ways of storing information still
> with us?
it's not a matter of being "stuck" with them. they have properties that
have not been duplicated in html readers, such as the ability to search a
series of predefined directories for the doc you want to read, much simpler
markup, integration with emacs (for info at least), faster startup times
than the average browser, command-line capable.
in short, i'd much rather read documentation with man or info than with
firefox. of course there's lynx and links, and w3m, and if someone would
ever take the trouble to build the other advantages of man and info into
them, and to convert all relevant documentation into html format, i
probably wouldn't really mind switching to html doc, but why would one go
through all that trouble just to duplicate functionality that already
exists?
but you know, info pages are generally generated from texinfo source files,
which can just as easily be converted to html (and even pdf). in fact, gnu
info pages are always available on the net in a variety of formats, among
which html (in two variants, even). so if you prefer, you can read any info
page as html. there are also several ways to convert man or t/nroff docs to
html.
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Mike
> Mike wrote:
>> So why are we still stuck with "man this" and "info that" and "xyz the
>> other" etc.? Why are these obscure, specialist, restrictive,
>> incantational, and arguably obsolete ways of storing information still
>> with us?
>
> it's not a matter of being "stuck" with them. they have properties that
> have not been duplicated in html readers, such as the ability to search
> a series of predefined directories for the doc you want to read, much
> simpler markup, integration with emacs (for info at least), faster
> startup times than the average browser, command-line capable.
MC + Lynx
And the advantage here is that you don't need specialist (can't do
anything else with them) apps to search/read the documentation, just a
couple of multi-purpose apps using long established and defined functions.
> in short, i'd much rather read documentation with man or info than with
> firefox. of course there's lynx and links, and w3m, and if someone would
> ever take the trouble to build the other advantages of man and info into
> them, and to convert all relevant documentation into html format, i
> probably wouldn't really mind switching to html doc, but why would one
> go through all that trouble just to duplicate functionality that already
> exists?
Because each app needs it's own crash course in how to actually use it,
and a problem with Linux/*NIX is that there are many ways to do
something, but also as many ways to do something. The number of times
I've hit the wrong application's key combo and had to break my
concentration to figure out what I just dismissed/swapped/deleted... Argh!
A counter question is surely "Why have so many apps for such similar
functions?"
I'd go with your Firefox comments, and the idea of developing a suitable
text browser to cover man/info documentation too.
> but you know, info pages are generally generated from texinfo source
> files, which can just as easily be converted to html (and even pdf). in
> fact, gnu info pages are always available on the net in a variety of
> formats, among which html (in two variants, even). so if you prefer, you
> can read any info page as html. there are also several ways to convert
> man or t/nroff docs to html.
Yup. I know they can be converted. If you can think it, somebody else
probably has too, and there's probably a Linux app to do the job. :)
My table thumping on this one is over how come a sometimes vital resource
(ie: Dayam! Is there a flag to [?] etc.) is still, (and I'm going to
stick with this one a bit longer here), an old app with it's own special
and unique keysets, functions, mysteries, etc. when a multi-use tool
regularly used for many similar functions (file manager/browser) could
work just as well or better.
Its kinda like having a special can opener just for "Soupy Soups" special
cans.
Mike
> Mike wrote:
>
>> What, I have to wonder, is the problem with html?
>
> That's the problem with newbies: they want everything to be a web page
> ...
Oh pur-leez! Just don't do that one. 'k?
>> Its universal, simple, and all but one single wood burning computer
>> somewhere up a mountain in Siberia actually has the capacity to read
>> html from the moment they are booted.
>
> Perhaps, but even that one computer in Siberia is able to process and
> display a manpage relatively quickly, so "man" is still the most
> universal.
Do I detect an edge here?
And as *I* invented this mystery computer, *I* get to say what it will
and won't process. So there! Thrrrp!
> Do you have an html reader that will search for a particular file,
> through a preset search-path, based on arguments you give it? See "man
> man" for details.
As I mentioned in another reply, MC+Lynx (for example) makes a reasonable
combo, plus these are multi-use tools, not specialist tools for
specialist formatted documentation. (Dayam! That sounds so M$!)
>> Ah mean tah say! Plain text is as searchable as a man/info page!
>
> Um ... a manpage *is* plain text, with some markup (sound familiar?) I
> would be very surprised if the same were not true of info pages, but I
> care too little about those to bother checking.
Again, specialist stuff, needing it's own "reader". Not quite in step
with the rest of the Linux "also makes a pot of tea" Multiverse.
> In fact, check out the man2html manpage (that would be "man man2html",
> of course ;-). I think you you'll find you *can* have your manpages in
> html.
Well, du-UH!
Got any advice on sucking eggs while you're at it? ;)
The key issue for me here is that man pages are in a special format that
require a special reader, with it's own logics and function keys etc.
Just how many individual methods of reading a page of text do we actually
need? How many binaries just to access/read basic information? Have we
not yet reached a point where we could define a standard that fits in
with other standards?
Maybe some kind of plain text thing with some markup? Hmmm? ;)
Sidney Lambe
I hope you realize that the email address I gave you is
the one I give to trolls and idiots like you. I never
check the mail there.
I know you think you fooled me with your line of bullshit.
But I knew from the moment I saw the common first name
in my newsreader's display that I was dealing with
a jerk who doesn't do anything but run his punk mouth.
[delete]
Joost Kremers
> MC + Lynx
>
> And the advantage here is that you don't need specialist (can't do
> anything else with them) apps to search/read the documentation, just a
> couple of multi-purpose apps using long established and defined functions.
i'm not very familiar with mc, but AFAIK mc+lynx still lacks some of the
functionality that makes man and info useful as documentation browsers. as
it stands, they're not a suitable replacement.
> Because each app needs it's own crash course in how to actually use it,
> and a problem with Linux/*NIX is that there are many ways to do
> something, but also as many ways to do something. The number of times
> I've hit the wrong application's key combo and had to break my
> concentration to figure out what I just dismissed/swapped/deleted... Argh!
i won't say it never happens to me that i hit the wrong key... but for me
it's not that much of an issue.
i have the same thing with xdvi, gv and xpdf. they're all document viewers,
but for different types of documents, and they all work slightly
differently. it's annoying, and i'd certainly prefer one single app that
handles dvi, ps and pdf files, but it OTOH it's not *that* bad.
> A counter question is surely "Why have so many apps for such similar
> functions?"
that's evolution for you. ;-) different people having similar itches coming
up with similar but incompatible solutions.
> My table thumping on this one is over how come a sometimes vital resource
> (ie: Dayam! Is there a flag to [?] etc.) is still, (and I'm going to
> stick with this one a bit longer here), an old app with it's own special
> and unique keysets, functions, mysteries, etc. when a multi-use tool
> regularly used for many similar functions (file manager/browser) could
> work just as well or better.
well, man just pipes its output through less, and since that's an app i use
quite a lot, man doesn't give me much trouble.
but in the end it all comes down to this: i agree there would be certain
advantages to having a single app that handles various documentation
sources, and it'd be ok if that single app were essentially a text browser
with the added functionality that a document browser needs. but in order
for that to happen, someone must get up and say "ok, i'm gonna do the work
required to build this app, and then i'm gonna try and get everybody sold
on it". that person's not going to be me, though, because the disadvantages
don't bother me all that much.
Dan C
> I hope you realize that the email address I gave you is
> the one I give to trolls and idiots like you. I never
> check the mail there.
>
> I know you think you fooled me with your line of bullshit.
>
> But I knew from the moment I saw the common first name
> in my newsreader's display that I was dealing with
> a jerk who doesn't do anything but run his punk mouth.
Ding!Ding!Ding! And there you have it, ladies and gentlemen! The final
proof, as if it was really needed, that "Sid" is really our old loser
friend "Tom Newton", who is really the ultimate Usenet loser, "Alan
Connor". It always works out this way, as he just can't help using some
of his trademark phrases.
I would like the record to show that I was the one who publicly spotted
him (again), and exposed to the world the complete and utter liar and
moron that this retarded whacko really is.
Time to dream up another name, Alan/Tom/Sid. It won't take long for you
to be outed again. Do us all a favor, and just disappear.
--
"Sidney Lambe" ("Tom Newton") - the latest nymshift of "Alan Connor".
Read more about the netkook Alan Connor here:
http://www.pearlgates.net/nanae/kooks/ac/fga.shtml
Email him: calh...@gmail.com or simple...@gmail.com
Grant
...
>with the added functionality that a document browser needs. but in order
>for that to happen, someone must get up and say "ok, i'm gonna do the work
>required to build this app, and then i'm gonna try and get everybody sold
>on it". that person's not going to be me, though, because the disadvantages
>don't bother me all that much.
This about sums up the GNU/Linux world doesn't it? We have much choice,
nothing's quite right, but 'good enough'. And often hardly worth the
effort make yet another frobnicator.
Years ago key macro expanders (can't think of a name) were the go on PC's
(using the term lightly, I wrote one in assembler for cp/m back then :) to
get similar functionality to 'alias' these days tied to odd key combinations.
But doc browsers sort of depend on environment, in a GUI there are different
methods compared to terminal (multi-tab browsers?) There are times I'd like
for man pages to hotlink into 'See also' pages, so I highlight a see-also,
exit and man Shft-Ins -> into related document, not that different a workaround.
At times I'm resorting to 'grep -r' keyword searches, 'cos apropos doesn't
help or I'm clueless as to where to start getting a handle on what some
function is named as.
Like an endless fractal expansion at times, looking for information...
Grant.
--
http://bugsplatter.id.au/
Keith Keller
> Responding to Rupa Zangpo:
>
>> Keith Keller wrote:
>>>> "man bash" also has a surprising amount of information.
>>>
>>> If by "surprising" you mean "difficult to navigate", I agree.
>>>
>>> Look up the INVOCATION section of the manpage for bash.
>>
>> No, no, no, NO! If you've got something to do with GNU Software, look up
>> the *info*-pages! 'info bash' is the way to go. There are no manpages
>> about GNU Software except the ones someone put together unofficially.
This may be true of many GNU manpages, but it doesn't appear to be true
of man bash. Normally you'd see a message in the SEE ALSO section
something like "The full documentation is in info blah", but that
message doesn't appear in man bash.
Plus info is based on emacs, which is the spawn of satan. ;-)
> What, I have to wonder, is the problem with html? Its universal, simple,
> and all but one single wood burning computer somewhere up a mountain in
> Siberia actually has the capacity to read html from the moment they are
> booted.
It can do man too. Old folks like me are used to man. Formatters can
convert a man page to HTML and/or vice-versa.
Sylvain Robitaille
>> That's the problem with newbies: they want everything to be a web
>> page ...
>
> Oh pur-leez! Just don't do that one. 'k?
It's an honest observation.
>> Perhaps, but even that one computer in Siberia is able to process and
>> display a manpage relatively quickly, ...
>
> And as *I* invented this mystery computer, *I* get to say what it will
> and won't process. So there! Thrrrp!
:-)
> As I mentioned in another reply, MC+Lynx (for example) makes a
> reasonable combo, plus these are multi-use tools, ...
To be honest, I've never found any use for mc, though I know some find
it very useful. It reminds me a little of "XTree" from the DOS days,
but I gather that it's intended to be a clone of "Norton Commander"
(which I thought was a poor copy of XTree, but anyway ...)
> not specialist tools for specialist formatted documentation. (Dayam!
> That sounds so M$!)
What is a web-browser, if not a "specialist tool for specialist
formatted documentation?"
>> Um ... a manpage *is* plain text, with some markup (sound familiar?)
>> ...
>
> Again, specialist stuff, needing it's own "reader". Not quite in step
> with the rest of the Linux "also makes a pot of tea" Multiverse.
What is an html file, if not "specialist stuff, needing it's own
"reader"?"
> Got any advice on sucking eggs while you're at it? ;)
Push me hard enough and I just might ... ;-)
> The key issue for me here is that man pages are in a special format
> that require a special reader, with it's own logics and function keys
> etc.
Well that's true of html files as well, though. The only difference,
then is that it seems that you've bothered to learn to use THAT software
and not the other, so you would like for the rest of us to give up the
way we've been working for years, just so you don't need to learn how
to use a different piece of software?
> Just how many individual methods of reading a page of text do we
> actually need? How many binaries just to access/read basic
> information? Have we not yet reached a point where we could define a
> standard that fits in with other standards?
Why weren't you demanding answers to those very questions when hypertext
was threatening to replace Gopher???
> Maybe some kind of plain text thing with some markup? Hmmm? ;)
Can your mc+lynx solution produce the kind of help that occurs when, say
for example, you have some idea what a page you're looking for is
basically about, but you don't know what it's called? "man -k $topic"
(or "apropos $topic") will give you a list of manual pages whose
descriptions contain the word $topic. That can be extremely useful (and
in fact I frequently use it myself).
Sylvain Robitaille
> i have the same thing with xdvi, gv and xpdf. they're all document
> viewers, but for different types of documents, and they all work
> slightly differently. it's annoying, and i'd certainly prefer one
> single app that handles dvi, ps and pdf files, but it OTOH it's not
> *that* bad.
But the different document formats have different functions. I prefer
to have a specific viewer, for example for .dvi files, with functions
that are specific to examining the details of such a file (in
particular, at least for the functionality I've used, to examine
typesetting details), which simply don't make sense when looking at
Postscript files (which consist of programming code normally used to
make printers spit out paper with ink/toner arranged on the pages in
specific meaningful patterns) or .pdf files, which are intended for
platform-independant distribution.
> ... i agree there would be certain advantages to having a single app
> that handles various documentation sources, and it'd be ok if that
> single app were essentially a text browser with the added
> functionality that a document browser needs.
Don't forget that it should also include an embedded lisp interpretter
... ;-)
Sylvain Robitaille
> Plus info is based on emacs, ...
Well THAT explains why that interface seems so counter-intuitive! It's
in the pedigree!
>> ... all but one single wood burning computer somewhere up a mountain
>> in Siberia actually has the capacity to read html from the moment
>> they are booted.
>
> It can do man too. ...
Apparently we have to let Mike decide whether it can. ;-)
Mike
> Mike wrote:
>
>>> That's the problem with newbies: they want everything to be a web page
>>> ...
>>
>> Oh pur-leez! Just don't do that one. 'k?
>
> It's an honest observation.
Nah. It was an assumption, and it was wrong.
>>> Perhaps, but even that one computer in Siberia is able to process and
>>> display a manpage relatively quickly, ...
>>
>> And as *I* invented this mystery computer, *I* get to say what it will
>> and won't process. So there! Thrrrp!
>
> :-)
>
>> As I mentioned in another reply, MC+Lynx (for example) makes a
>> reasonable combo, plus these are multi-use tools, ...
>
> To be honest, I've never found any use for mc, though I know some find
> it very useful. It reminds me a little of "XTree" from the DOS days,
> but I gather that it's intended to be a clone of "Norton Commander"
> (which I thought was a poor copy of XTree, but anyway ...)
T'were only a suggestion. There are other options. My point was that
multi-use tools can do the same job. No need for a specialist reader with
it's own special format and own special documentation.
>> not specialist tools for specialist formatted documentation. (Dayam!
>> That sounds so M$!)
>
> What is a web-browser, if not a "specialist tool for specialist
> formatted documentation?"
Web browser = common format
Man reader = specialist format
Web browser = in common use
Man reader = one single purpose
See what I'm looking at here?
>>> Um ... a manpage *is* plain text, with some markup (sound familiar?)
>>> ...
>>
>> Again, specialist stuff, needing it's own "reader". Not quite in step
>> with the rest of the Linux "also makes a pot of tea" Multiverse.
>
> What is an html file, if not "specialist stuff, needing it's own
> "reader"?"
See above comments about specialist tools.
>> Got any advice on sucking eggs while you're at it? ;)
>
> Push me hard enough and I just might ... ;-)
Ooer! Better watch me step then! 8(
>> The key issue for me here is that man pages are in a special format
>> that require a special reader, with it's own logics and function keys
>> etc.
>
> Well that's true of html files as well, though.
Again, see above comments about single-purpose specialist tools/formats.
> The only difference,
> then is that it seems that you've bothered to learn to use THAT software
> and not the other, so you would like for the rest of us to give up the
> way we've been working for years, just so you don't need to learn how to
> use a different piece of software?
Learn to use any browser, access html with ease.
Lean to use man-page reader, learn on single-purpose tool, and /have/ to
use it to read man pages. That, as I made myself aware of in another
post, seems very M$ in it's man-ifestation ( :)
>> Just how many individual methods of reading a page of text do we
>> actually need? How many binaries just to access/read basic information?
>> Have we not yet reached a point where we could define a standard that
>> fits in with other standards?
>
> Why weren't you demanding answers to those very questions when hypertext
> was threatening to replace Gopher???
html is a better multi-purpose option.
>> Maybe some kind of plain text thing with some markup? Hmmm? ;)
>
> Can your mc+lynx solution produce the kind of help that occurs when, say
> for example, you have some idea what a page you're looking for is
> basically about, but you don't know what it's called? "man -k $topic"
> (or "apropos $topic") will give you a list of manual pages whose
> descriptions contain the word $topic. That can be extremely useful (and
> in fact I frequently use it myself).
If somebody can't write up some development code to extend the functions
of commonly used applications like file managers and html browsers, then
we might as well sign up for Vasta. :(
C'maaahn! You KNOW what I'm talking about here!
The reason we're all still using the man-page format is because we've
learned to use it. If we were starting from scratch, with no idea to
begin with, many would be asking "Why is this basic documentation in such
a weird format that needs it's own reader?"
This is Linux after all, and the old "We've always done things this way"
excuse only works for the *BSD collective y'know. ;)
Mike
Aha! So I'm not alone!
Need information - seek documentation - read documentation.
Search FOR documentation - search documentation.
How many formats do we need here? How many different "how to operate this
application" documents do we need to read and learn off by heart? This
ends up being like having to learn to drive cars, tractors, combined
harvesters, fly aircraft, helicopters, operated submarines, motorcycles,
and various other vehicles, just to get to the shops.
And all for just a text document with markup.
So, my question has evolved into...
* Why do we need a specialist reader/format for basic information?
And, Are we still using the "traditional format" simply because old hands
got used to it and newbies had just better learn it or get ignored?
Its a thought.
Mike
> Mike <N...@Arizona.Bay> wrote:
>
> I hope you realize that the email address I gave you is the one I give
> to trolls and idiots like you. I never check the mail there.
>
> I know you think you fooled me with your line of bullshit.
>
> But I knew from the moment I saw the common first name in my
> newsreader's display that I was dealing with a jerk who doesn't do
> anything but run his punk mouth.
>
> [delete]
>
> Sid
Sid. You need therapy, not a newsreader.
Seriously.
Byeee.
Mike
> Keith Keller wrote:
>
>> Plus info is based on emacs, ...
>
> Well THAT explains why that interface seems so counter-intuitive! It's
> in the pedigree!
>
>>> ... all but one single wood burning computer somewhere up a mountain
>>> in Siberia actually has the capacity to read html from the moment they
>>> are booted.
>>
>> It can do man too. ...
>
> Apparently we have to let Mike decide whether it can. ;-)
I know somebody who's going to get his legs slapped pretty soon!
Gotta agree with the Emacs thing though. As a demonstration of how
convoluted the human brain can be and still remain conscious, its a work
of art, but as a practical application its BorgTech. No WAY could a
normal human mind adapt to using Emacs without significant and permanent
bio-tech alteration. Not without a plate full of strangely coloured
mushrooms that is. %)
Which, as was pointed out here, does leave it's footprint in other apps.
Which now indicates we have enough material to have a flame war. :(
Lets just tip-toe away quietly before the BSDers get wind of it... :)
Grant
...
>> Like an endless fractal expansion at times, looking for information...
>>
>> Grant.
>
>
>Aha! So I'm not alone!
>
>
>Need information - seek documentation - read documentation.
>
>Search FOR documentation - search documentation.
>
>How many formats do we need here? How many different "how to operate this
>application" documents do we need to read and learn off by heart? This
>ends up being like having to learn to drive cars, tractors, combined
>harvesters, fly aircraft, helicopters, operated submarines, motorcycles,
>and various other vehicles, just to get to the shops.
>
>And all for just a text document with markup.
>
>So, my question has evolved into...
>
>* Why do we need a specialist reader/format for basic information?
We don't -- man pages are text with markup, just like web pages, just
a different breed of markup, that's all. Your argument is weak...
>And, Are we still using the "traditional format" simply because old hands
>got used to it and newbies had just better learn it or get ignored?
No, It aint broke so nobody's gonna fix it -- feel free to delete
all your man pages, wont upset me at all.
>Its a thought.
o_O
Grant.
Grant
...
>Gotta agree with the Emacs thing though. As a demonstration of how
>convoluted the human brain can be and still remain conscious, its a work
>of art, but as a practical application its BorgTech. No WAY could a
>normal human mind adapt to using Emacs without significant and permanent
>bio-tech alteration. Not without a plate full of strangely coloured
>mushrooms that is. %)
Very good, I've read some people use linux or *BSD to boot emacs, I'm
not one of them...
Grant.
--
http://bugsplatter.id.au/
Loki Harfagr
> And all for just a text document with markup.
>
> So, my question has evolved into...
>
> * Why do we need a specialist reader/format for basic information?
you don't, if you want to use the man page as straight text just
tells it so:
# man man -P cat
you can even preset this and forget about it:
# export MANPAGER=/bin/cat
but it's all nitcpicking with a hay fork, the dire problem with
manpages is not "how can we read them" but "can we read them" ;-)
Mark Madsen
>> Just how many individual methods of reading a page of text do we
>> actually need? How many binaries just to access/read basic information?
>> Have we not yet reached a point where we could define a standard that
>> fits in with other standards?
>
> Why weren't you demanding answers to those very questions when hypertext
> was threatening to replace Gopher???
Hypertext replaced Gopher? Damnation, why wasn't I told?!
When did that happen, anyway?
Mark Madsen
> but it's all nitcpicking with a hay fork, the dire problem with manpages
> is not "how can we read them" but "can we read them" ;-)
</modquote>
Michael Black
I was looking at the "Idiot's Guide to the Internet" from 1993 or '94
last year at a book sale, and right out of the gate about four chapters
had no relevance to today's user, since they covered protocol's that
aren't really in use anymore. For most people, they wouldn't even
know about Gopher, since they came late enough that its time had
already passed.
McGill University here used gopher for a classified ad thing for a long
time. I was going to say up until reasonably recently, but by now it's
been a fair number of years since they switched over to an html format.
But when it suddenly changed over, it seemed dramatic.
Michael
Mike
[...]
>>
>>So, my question has evolved into...
>>
>>* Why do we need a specialist reader/format for basic information?
>
> We don't -- man pages are text with markup, just like web pages, just a
> different breed of markup, that's all. Your argument is weak...
So I CAN read them in my browser then, a tool that my fingers know
instinctively, without having to read up on the reader I needed to read
about something else? No... hang on... just tried it. It doesn't WORK
that way! Dayam! I need a special reader to read those pages! :(
Guess my "argument" (it was a question when I started) is still standing.
>>And, Are we still using the "traditional format" simply because old
>>hands got used to it and newbies had just better learn it or get
>>ignored?
>
> No, It aint broke so nobody's gonna fix it -- feel free to delete all
> your man pages, wont upset me at all.
Not quite the point. Miss a turn.
(Nice pout BTW :)
>>Its a thought.
>
> o_O
>
> Grant.
Granted. ;)
Mike
Yeah, I KNOW things can be converted/scripted/altered, but thats not the
point of my question.
Why do we need a special reader for specially formatted documentation at
all? This is a legacy thing, and I suppose I'm arguing that its not only
obsolete, but arguably time consuming and distracting for today's Linux
user base.
"We've always done it this way" doesn't cut the mustard when you've jobs
waiting and need to fix something before something else happens as a
result.
Or do we assume all Linux users go through a Linux Training Camp before
being allowed near a live terminal? "If you have a problem you WILL read
your man pages. IF you don't know all the tricks to using your man page
reader you WILL have another problem. IF you have another problem you
WILL NOT solve your first problem UNTIL you have learned to fly your man
page reader upside down while making a cup of tea and compiling the
latest X.org server in French! DO I MAKE MYSELF CLEAR MAGGOTS?" "SIR! YES
SIR!"
etc.
Most people reach for the documentation when something has gone wrong, or
they get stuck. At that precise point, the LAST thing they need is to
find the documentation in a specialist format, AND have to go reading up
on how to use a dedicated single-purpose reader with no interface to
speak of (ie: you know it or you don't). This is why there are man2html
converters out there, and man2text converters, etc.
What I'm looking at is why this preference for a standard format (many
common apps can read it) has not become THE standard yet. The only thing
I'm discovering is that the "We've always done it this way" thing coupled
with the "If it ain't broke..." thing has left this legacy still fully
functional, but still obscure and unique, in most default OS
distributions.
Be honest. If the man page format did not already exist, would anybody
actually invent it today?
Dan C
>>>* Why do we need a specialist reader/format for basic information?
>> We don't -- man pages are text with markup, just like web pages, just a
>> different breed of markup, that's all. Your argument is weak...
> So I CAN read them in my browser then, a tool that my fingers know
> instinctively, without having to read up on the reader I needed to read
> about something else? No... hang on... just tried it. It doesn't WORK
> that way! Dayam! I need a special reader to read those pages! :(
Yeah. A "special reader" which you already have, and is already on any
*nix system you may stumble upon. One which works fine, and is very
simple to use. Gee, what a terrible situation...
> Guess my "argument" (it was a question when I started) is still standing.
I would guess "not".
>> No, It aint broke so nobody's gonna fix it -- feel free to delete all
>> your man pages, wont upset me at all.
> Not quite the point. Miss a turn.
It's exactly the point. It ain't broke. Nobody's gonna fix it. Not to
mention the fact that on many systems, there is NOT an HTML-capable
browser available to use. Did you not know that?
--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
The Usenet Improvement Project: http://improve-usenet.org
Michael Black
> Responding to Grant:
>
> [...]
>>>
>>> So, my question has evolved into...
>>>
>>> * Why do we need a specialist reader/format for basic information?
>>
>> We don't -- man pages are text with markup, just like web pages, just a
>> different breed of markup, that's all. Your argument is weak...
>
> So I CAN read them in my browser then, a tool that my fingers know
> instinctively, without having to read up on the reader I needed to read
> about something else? No... hang on... just tried it. It doesn't WORK
> that way! Dayam! I need a special reader to read those pages! :(
>
I just looked at a man page with lynx, and it displays fine, the only
difference being the lack of highlighting, which perhaps can be fixed
with some changes to a config file.
I think, though, that you are arguing a false point. In the seven
years I've been using Linux (which means seven years of using Slackware),
I've never seen man as anything but invisible. It never gets in
the way, it just displays the man page without any fuss. Indeed,
I don't even think about how I'm invoking a command titled "man"
and passing to it the specific man page I want to read, I think of
it as looking at the man page for the thing I'm wanting to read.
The man command is as invisible as cd or ls.
Michael
Jim Diamond
> Responding to Loki Harfagr:
>
>> On Sun, 28 Sep 2008 09:19:40 +0000, Mike sprout:
>>
>>> And all for just a text document with markup.
>>>
>>> So, my question has evolved into...
>>>
>>> * Why do we need a specialist reader/format for basic information?
>>
>> you don't, if you want to use the man page as straight text just
>> tells it so:
>> # man man -P cat
>>
>> you can even preset this and forget about it:
>> # export MANPAGER=/bin/cat
>>
>> but it's all nitcpicking with a hay fork, the dire problem with manpages
>> is not "how can we read them" but "can we read them" ;-)
>
>
> Yeah, I KNOW things can be converted/scripted/altered, but thats not the
> point of my question.
>
> Why do we need a special reader for specially formatted documentation at
> all?
Maybe because it does a better job than using a web (oops, HTML) browser?
Can your HTML browser do regular expression searches?
Can you set "bookmarks" at specific lines with your HTML browser so
that you can easily flip back and forth in the man page you are reading?
Can you imagine that not everyone wants to use some piece of bloatware
every time they want to do something simple?
> This is a legacy thing, and I suppose I'm arguing that its not only
> obsolete, but arguably time consuming and distracting for today's
> Linux user base.
Your argument so far is very weak, please share some good points with
me, I'm always keen to know about better ways to do things.
> "We've always done it this way" doesn't cut the mustard when you've
> jobs waiting and need to fix something before something else happens
> as a result.
Does this have something to do with reading man pages?
> Or do we assume all Linux users go through a Linux Training Camp before
> being allowed near a live terminal? "If you have a problem you WILL read
> your man pages. IF you don't know all the tricks to using your man page
> reader you WILL have another problem. IF you have another problem you
> WILL NOT solve your first problem UNTIL you have learned to fly your man
> page reader upside down while making a cup of tea and compiling the
> latest X.org server in French! DO I MAKE MYSELF CLEAR MAGGOTS?" "SIR! YES
> SIR!"
Apparently you find your MANPAGER program (less, in my case) much more
difficult to use than most people. But really, it isn't that hard to
use it in a minimalist way. And if/when you come to the realization
that you want something that is more than minimalist, you will find
that there are other features to facilitate your man page reading.
> Be honest. If the man page format did not already exist, would anybody
> actually invent it today?
That's a good question, which probably none of us can answer
definitively. But people who aren't happy with the limitations of HTML
browsers might invent something else.
Cheers.
Jim
Mark Madsen
> Why do we need a special reader for specially formatted documentation at
> all? This is a legacy thing, and I suppose I'm arguing that its not only
> obsolete, but arguably time consuming and distracting for today's Linux
> user base.
Documentation is a total waste of time anyway. To benefit from it one
needs to learn to read, and that takes an unbelievable amount of time
that could more enjoyably be spent banging rocks together.
And the people who write the documentation need to learn to write first,
even if they already know how to read. How long does that take?
Not only that, but the human brain consumes 20W. If we could all turn
them off, the world could save about 1.4x10^11W. So don't let anyone
ever try to tell you that Linux is more energy efficient than Windows.
Beej Jorgensen
>Yeah, I KNOW things can be converted/scripted/altered
Read this as: you don't need a special reader because the data can be
converted into whatever format you want.
>Why do we need a special reader for specially formatted documentation
>at all?
Of course we don't "need" it. It's what's there and it works for a
great many people. Lots of browsers display man pages, too.
>Be honest. If the man page format did not already exist, would anybody
>actually invent it today?
No, it would be XML. It definitely would not be HTML.
The current best solution would probably be use a man-to-Docbook
converter and go from there. If you think there's a need for
prepackaged man pages in XML, do it. Distribute it to anyone who wants
it.
There's absolutely no one stopping you. Really!
-Beej
~kurt
>
> If by "surprising" you mean "difficult to navigate", I agree.
>
> what files are sourced on startup. You'll see that there might be good
Yea, I had something really screwed up with my startup a while back and couldn't
figure out where it was coming from - had to turn to the man page to figure it
out.
- Kurt
~kurt
>
> No, no, no, NO! If you've got something to do with GNU Software, look up
> the *info*-pages! 'info bash' is the way to go. There are no manpages
> about GNU Software except the ones someone put together unofficially.
I hate info - can't figure out how to navigate it. I guess I can read
the man pages on it....
- Kurt
Lew Pitcher
(rupa....@web.de) wrote:
> Keith Keller wrote:
>>> "man bash" also has a surprising amount of information.
>>
>> If by "surprising" you mean "difficult to navigate", I agree.
>>
>> Look up the INVOCATION section of the manpage for bash.
>
> No, no, no, NO! If you've got something to do with GNU Software, look up
> the *info*-pages! 'info bash' is the way to go.
Hmmmmm... It looks like the info page disagrees with you
File: bash.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir)
Bash Features
*************
This text is a brief description of the features that are present in
the Bash shell (version 3.1, 30 December 2005)..
[snip]
This manual is meant as a brief introduction to features found in
Bash. The Bash manual page should be used as the definitive reference
on shell behavior.
Note the last statement above: "The Bash manual page should be used as the
definitive reference on shell behaviour".
> There are no manpages
> about GNU Software except the ones someone put together unofficially.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Lew Pitcher
> No, no, no, NO!
[snip]
> There are no manpages
> about GNU Software except the ones someone put together unofficially.
It looks like you are wrong about that one as well (note the organization
that author Brian Fox represents)
From "man 1 bash"
AUTHORS
Brian Fox, Free Software Foundation
bf...@gnu.org
Chet Ramey, Case Western Reserve University
ch...@po.cwru.edu
Michael Black
> On September 27, 2008 08:57, in alt.os.linux.slackware, Rupa Zangpo
> (rupa....@web.de) wrote:
>
>> Keith Keller wrote:
>>>> "man bash" also has a surprising amount of information.
>>>
>>> If by "surprising" you mean "difficult to navigate", I agree.
>>>
>>> Look up the INVOCATION section of the manpage for bash.
>>
>> No, no, no, NO! If you've got something to do with GNU Software, look up
>> the *info*-pages! 'info bash' is the way to go.
>
> Hmmmmm... It looks like the info page disagrees with you
>
> File: bash.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir)
>
> Bash Features
> *************
>
> This text is a brief description of the features that are present in
> the Bash shell (version 3.1, 30 December 2005)..
>
> [snip]
> This manual is meant as a brief introduction to features found in
> Bash. The Bash manual page should be used as the definitive reference
> on shell behavior.
>
> Note the last statement above: "The Bash manual page should be used as the
> definitive reference on shell behaviour".
>
There is an inconsistency there. I've seen man pages that say the
reverse, that the info page is the definitive source.
And sadly, not every program has a man page.
I've already posted about how easy man is to use that I never think of
it as a standalone utility.
A clear advantage over using a browser is that man will find the man
pages if they are were they should be. A browser, you either have
to remember where the man pages are stored, or browse through the
directory structure.
Man is so easy to use, that I've considered making up some man pages
of my own, for purely local use. Not instructions on using a specific
program, but a "man page" for some tiny bits of information that I
want to keep handy but can never remember. Or a "man page" of common
invocations of utilities and applications I use regularly, sort of
a cheat sheet.
I have those as text files, and it is easy enough to use Lynx to
look them over. Yet, I still have to get to the file, while
"man cheat" or "man birthdays" would get the information up on
the screen faster than I can blink.
That seems to be what unix/linux is about. Simple programs that
do things well. Which is why I use "cal" a lot more than all
the fancier things I have on my hard drive, and I use "look" constantly
to check the spelling of words. These are wonderful things that
get used. Even to use more recent examples, I could invoke some fancy
audio editing system to bring audio files to a constant level, or
I could just use "normalize" to do it, and not have to fuss with
menus or multiple options.
Michael
No_One
> Responding to Loki Harfagr:
>
>> On Sun, 28 Sep 2008 09:19:40 +0000, Mike sprout:
>>
>>> And all for just a text document with markup.
>>>
>>> So, my question has evolved into...
>>>
>>> * Why do we need a specialist reader/format for basic information?
>>
>> you don't, if you want to use the man page as straight text just
>> tells it so:
>> # man man -P cat
>>
>> you can even preset this and forget about it:
>> # export MANPAGER=/bin/cat
>>
>> but it's all nitcpicking with a hay fork, the dire problem with manpages
>> is not "how can we read them" but "can we read them" ;-)
>
>
> Yeah, I KNOW things can be converted/scripted/altered, but thats not the
> point of my question.
>
> Why do we need a special reader for specially formatted documentation at
> all? This is a legacy thing, and I suppose I'm arguing that its not only
> obsolete, but arguably time consuming and distracting for today's Linux
> user base.
Explain why it's time consuming....why it's a distraction...saying so
doesn't make it so.
>
> "We've always done it this way" doesn't cut the mustard when you've jobs
> waiting and need to fix something before something else happens as a
> result.
The man reader prevents you from completing jobs....is that your point here?
I love to "hear" the explanation for this piece of rubbish.
ken
Helmut Hullen
Du meintest am 28.09.08:
> I hate info - can't figure out how to navigate it. I guess I can
> read the man pages on it....
Try pinfo
from slacky.eu
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Chick Tower
> Responding to Sylvain Robitaille:
>> What is a web-browser, if not a "specialist tool for specialist
>> formatted documentation?"
>
> Web browser = common format
>
> Man reader = specialist format
>
> Web browser = in common use
>
> Man reader = one single purpose
>
> See what I'm looking at here?
Not really, Mike. According to the man page on man, it uses less by
default. You know, less, the general-purpose text viewer.
--
Chick Tower
For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
Chick Tower
> Be honest. If the man page format did not already exist, would anybody
> actually invent it today?
Good point. We also need to reinvent zippers to notify our cell phones
via BlueTooth when they are not closed, to avoid that embarrassment.
Until that time, zippers are arcane, obsolete hardware that should not be
trusted. Codpieces are the only sane alternative.
To answer your question, yes, someone would invent man pages if they did
not already exist. Do you think they, and info pages, and their storage
formats, were invented simply as programming exercises not meant to
meet any real-world needs? The format might well be different, but they
would be easily readable and searchable via command-line utilities, since
they are intended to explain the use of command-line programs, which are
still important in the Unix, Linux, and BSD worlds. Graphical programs
have help systems of their own, with graphical interfaces.
Chick Tower
> So I CAN read them in my browser then, a tool that my fingers know
> instinctively, without having to read up on the reader I needed to read
> about something else? No... hang on... just tried it. It doesn't WORK that
> way! Dayam! I need a special reader to read those pages! :(
Use Konqueror to read your man and info pages if you insist upon using a
web browser to do so. See the help.
Keith Keller
> On Sun, 28 Sep 2008, Lew Pitcher wrote:
>>
>> Note the last statement above: "The Bash manual page should be used as the
>> definitive reference on shell behaviour".
>>
> There is an inconsistency there. I've seen man pages that say the
> reverse, that the info page is the definitive source.
There's no inconsistency. man bash happens to be authoritative for
bash. man sort (which has the message you describe) is not
authoritative for sort. It all depends on what the authors of the
program have chosen to do.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Mike
> On Sun, 28 Sep 2008 14:21:39 +0000, Mike wrote:
>
>> So I CAN read them in my browser then, a tool that my fingers know
>> instinctively, without having to read up on the reader I needed to read
>> about something else? No... hang on... just tried it. It doesn't WORK
>> that way! Dayam! I need a special reader to read those pages! :(
>
> Use Konqueror to read your man and info pages if you insist upon using a
> web browser to do so. See the help.
/usr/man/man.1.gz
"What should Seamonkey do with this file?" etc.
If Konk has the ability to read man pages, then this is an extension, not
a "default browser" state. Not quite what was talking about, but
interesting.
Mike
> On Sun, 28 Sep 2008, Mike wrote:
>
>> Responding to Grant:
>>
>> [...]
>>>>
>>>> So, my question has evolved into...
>>>>
>>>> * Why do we need a specialist reader/format for basic information?
>>>
>>> We don't -- man pages are text with markup, just like web pages, just
>>> a different breed of markup, that's all. Your argument is weak...
>>
>> So I CAN read them in my browser then, a tool that my fingers know
>> instinctively, without having to read up on the reader I needed to read
>> about something else? No... hang on... just tried it. It doesn't WORK
>> that way! Dayam! I need a special reader to read those pages! :(
>>
> I just looked at a man page with lynx, and it displays fine, the only
> difference being the lack of highlighting, which perhaps can be fixed
> with some changes to a config file.
Or, if the man pages themselves were html/html compatible... ?
> I think, though, that you are arguing a false point. In the seven years
> I've been using Linux (which means seven years of using Slackware), I've
> never seen man as anything but invisible. It never gets in the way, it
> just displays the man page without any fuss. Indeed, I don't even think
> about how I'm invoking a command titled "man" and passing to it the
> specific man page I want to read, I think of it as looking at the man
> page for the thing I'm wanting to read.
>
> The man command is as invisible as cd or ls.
>
I understand that. I'm not arguing that. I'm looking specifically a the
fact man pages are written to be primerily read by a special reader,
dedicated to just that purpose, and thats not a very "Linux" way to do
things compared to the extensible range of things other Linux apps can
typically be called upon to do.
Sure, a little ingenuity can fix things, convert the man pages, extend
the capacity of a browser, but the basic setup is still the "old way".
I'm asking why this old way is still "the standard" and suggesting its
obsolete, only still there because of a cycle of old hands used to using
it, and newbies feeling as if they need to get up to speed with it as if
it is some kind of magic Linux thing, which it isn't, and only figuring
out later than its function-specific legacy software, not something with
supa-dupa functions nothing else can do. The fact its so ingrained and
"traditional" in most/all distros is probably why its still there.
Mike
> On Sun, 28 Sep 2008 09:04:59 +0000, Mike wrote:
>
>> Responding to Sylvain Robitaille:
>>> What is a web-browser, if not a "specialist tool for specialist
>>> formatted documentation?"
>>
>> Web browser = common format
>>
>> Man reader = specialist format
>>
>> Web browser = in common use
>>
>> Man reader = one single purpose
>>
>> See what I'm looking at here?
>
> Not really, Mike. According to the man page on man, it uses less by
> default. You know, less, the general-purpose text viewer.
Just tried Seamonkey and Lynx to view the man man page.
Not impressive.
Next up, trying to read Google's homepage using "man google".
I'n not saying that the man page reader is "OMG!" bad, just that its a
dedicated format with a dedicated reader. Sure, with a little fiddling
one can get past that and force things to work beyond design, but thats
not the point I'm making. HTML is, I'm sure you would agree, an
internationa standard, and is also plain text with markup, except its
readable in any browser, anywhere, with no fiddlings or time spent trying
to figure out how to "repair" the differences between the formats if one
is so moved to do so. HTML is alread there and requires no extra learning
of yet another app. IOW, its already integral with a user's existing
application awareness.
Mike
> On 2008-09-28 at 11:33 ADT, Mike <N...@Arizona.Bay> wrote:
>> Responding to Loki Harfagr:
>>
>>> On Sun, 28 Sep 2008 09:19:40 +0000, Mike sprout:
>>>
>>>> And all for just a text document with markup.
>>>>
>>>> So, my question has evolved into...
>>>>
>>>> * Why do we need a specialist reader/format for basic information?
>>>
>>> you don't, if you want to use the man page as straight text just
>>> tells it so:
>>> # man man -P cat
>>>
>>> you can even preset this and forget about it:
>>> # export MANPAGER=/bin/cat
>>>
>>> but it's all nitcpicking with a hay fork, the dire problem with
>>> manpages is not "how can we read them" but "can we read them" ;-)
>>
>>
>> Yeah, I KNOW things can be converted/scripted/altered, but thats not
>> the point of my question.
>>
>> Why do we need a special reader for specially formatted documentation
>> at all?
>
> Maybe because it does a better job than using a web (oops, HTML)
> browser?
>
> Can your HTML browser do regular expression searches?
>
> Can you set "bookmarks" at specific lines with your HTML browser so that
> you can easily flip back and forth in the man page you are reading?
>
> Can you imagine that not everyone wants to use some piece of bloatware
> every time they want to do something simple?
Lynx is hardly bloatware. Lets get rid of the idea that Firefox is the
only browser on the planet shall we?
As for the functions you describe here, surely developing a browser to
include these functions makes more sense than investing in a single-
purpose reader application? (More on this further down.)
>> This is a legacy thing, and I suppose I'm arguing that its not only
>> obsolete, but arguably time consuming and distracting for today's Linux
>> user base.
> Your argument so far is very weak, please share some good points with
> me, I'm always keen to know about better ways to do things.
Sarcasm isn't helping here, and indicates a weak stance. Lets tip-toe
away from the potential for a flaming as thats not what I'm seeking here.
>> "We've always done it this way" doesn't cut the mustard when you've
>> jobs waiting and need to fix something before something else happens as
>> a result.
> Does this have something to do with reading man pages?
Sarcasm again. Lets leave that.
>> Or do we assume all Linux users go through a Linux Training Camp before
>> being allowed near a live terminal? "If you have a problem you WILL
>> read your man pages. IF you don't know all the tricks to using your man
>> page reader you WILL have another problem. IF you have another problem
>> you WILL NOT solve your first problem UNTIL you have learned to fly
>> your man page reader upside down while making a cup of tea and
>> compiling the latest X.org server in French! DO I MAKE MYSELF CLEAR
>> MAGGOTS?" "SIR! YES SIR!"
> Apparently you find your MANPAGER program (less, in my case) much more
> difficult to use than most people. But really, it isn't that hard to
> use it in a minimalist way. And if/when you come to the realization
> that you want something that is more than minimalist, you will find that
> there are other features to facilitate your man page reading.
See above comments on investing in developing browser capacity rather
than a single-purpose application.
Yeah, one can learn the intricacies of the man reader, but thats what I'm
talking about. Its a form of "app-creep". Every little thing needing it's
own app, with it's own set of function keys, mindset. logics, flags, etc.
etc. etc.
While the idea of a single killer-app might not appear to some/many, IMO
the man reader thing is heading in the other direction, and in some ways
echoes the M$ way of imposing more complications than are necessary on
the end user, when there are simpler and more direct ways of delivering
that content.
>> Be honest. If the man page format did not already exist, would anybody
>> actually invent it today?
> That's a good question, which probably none of us can answer
> definitively. But people who aren't happy with the limitations of HTML
> browsers might invent something else.
Ok. Let me take a shot at it then. No. Nobody would write the man page
reader as somebody else would have said "Hey! Lets use HTML if we need
markup!" and somebody else would have said "Hey! Lets extend XYZ browser
to give us bookmarking functions and other cool stuff!" and so on...
I propose that the ONLY real reason anybody uses the man page reader
stuff is because its already there, and "we've always done it this way",
plus, the subtle but "in there" defensive responses I'm seeing are
typical of any suggestion of change being made to people who pride
themselves in their skill with something.
To illustrate my point some more...
I used to use SLRN, and spent the time and frustration learning all the
extra keys required to cope with that pretty little box at the top that
does nothing the design of Pine cannot do. I learned how to knock up and
maintain "on the fly" multiple complex score files, invent and maintain
complext score ratings for post details, and interpret them
instinctively. I became almost one with the machine.
Then my arthritis flared up, and the spelling mistakes got wors, and the
"Oops!" increased as my fingers hit some obscure key combo instead of
what I was trying to write...
So, with heavy heart, I tried (amongst others) Pan. What a miserable
Windows-esque offering compared to SLRN to be sure! (Proud of my skill
with SLRN y'see!)
A few months back I set up SLRN again, and, having now got used to Pan,
and its quirks and foibles, found SLRN a nightmre of complexity compared
to the simple direct funcionality of Pan.
If someone had suggested I switch to Pan back in my "I'm using SLRN Mom!
Look at meeeee!" days, I'd have been just as dismissive as I'm reading
here on this thread ATM. As it is, change occured, I adapted, and now can
enjoy usenet again with mimimal arthritic pain, AND I can concentrate
much better on the posts themselves instead of switching my brain between
usenetting and fiddling with multiple scores/configs/etc.
Now I'm not saying SLRN is in any way defective or "not fit for purpose".
Far from it, its an amazing app and I wish I had the dexterity to use it
like I used to, but times change, and I found myself in a position where
I needed to rethink how I did things.
I'm suggesting that the time to rethink things regarding the man page
reader thing is not only here, but has been for some time.
Mike
Best response so far. Nice one. :)
P.S. Might I suggest somebody does something with that last paragraph,
for the record? Worthy quote material if ever I saw it.
Mike
Good suggestions all, but missing the point once more.
Grant
>Responding to Chick Tower:
>
>> On Sun, 28 Sep 2008 09:04:59 +0000, Mike wrote:
>>
>>> Responding to Sylvain Robitaille:
>>>> What is a web-browser, if not a "specialist tool for specialist
>>>> formatted documentation?"
>>>
>>> Web browser = common format
>>>
>>> Man reader = specialist format
>>>
>>> Web browser = in common use
>>>
>>> Man reader = one single purpose
>>>
>>> See what I'm looking at here?
>>
>> Not really, Mike. According to the man page on man, it uses less by
>> default. You know, less, the general-purpose text viewer.
>
>
>Just tried Seamonkey and Lynx to view the man man page.
It's the ID ten T problem, methinks.
Try: man -P cat man
Grant.
--
http://bugsplatter.id.au/
Mike
You appear to be looking for a flame here, and I'm not.
Mike
> On Sun, 28 Sep 2008 14:33:32 +0000, Mike wrote:
>
>> Be honest. If the man page format did not already exist, would anybody
>> actually invent it today?
>
> Good point. We also need to reinvent zippers to notify our cell phones
> via BlueTooth when they are not closed, to avoid that embarrassment.
> Until that time, zippers are arcane, obsolete hardware that should not
> be trusted. Codpieces are the only sane alternative.
You got this the wrong way around.
> To answer your question, yes, someone would invent man pages if they did
> not already exist. Do you think they, and info pages, and their storage
> formats, were invented simply as programming exercises not meant to meet
> any real-world needs? The format might well be different, but they
> would be easily readable and searchable via command-line utilities,
> since they are intended to explain the use of command-line programs,
> which are still important in the Unix, Linux, and BSD worlds. Graphical
> programs have help systems of their own, with graphical interfaces.
Not "invent man pages" but "invent the current man page reader".
Keep up at the back will you! ;)
Dan C
> I'm asking why this old way is still "the standard" and suggesting its
> obsolete, only still there because of a cycle of old hands used to using
> it, and newbies feeling as if they need to get up to speed with it as if
I already answered this in another post, but here it is again: Not all
*nix systems have a web browser available for viewing man pages, n00b.
Mike
This demonstates my point, that this needs to be done, and you need to
know that it can be done, and then how to do it.
If, for example, the documentation was in HTML/XML format by default, it
could be converted into man format as required in the same way, from a
common format to a prefered specialist format, but I strongly suspect
that if the standard was browser-based and not based on a single-task
specific application, browsers would aquire the extended functions to do
the same things the man reader does ATM as part of their range of
multiple functions.
Sylvain Robitaille
>> Explain why it's time consuming....why it's a distraction...saying so
>> doesn't make it so.
...
>> The man reader prevents you from completing jobs....is that your
>> point here?
Mike replied:
> You appear to be looking for a flame here, and I'm not.
I think you missed the above, which appear to me, in fact, to be rather
valid questions (ok, one is a request, not a question). Which part of
"man" gives you so much trouble?
You pointed out that if this format were to be created today, people would
likely turn to HTML instead, and extend HTML-capable viewers to contain
some of the same features as "man" (which, in fact, is a combination of
nroff, or groff on Linux, and more, or "less" on Linux).
The fact is the extensions to the HTML viewer(s) (plural because no one
would want to be stuck *having* to use the same one as everyone else)
would need to come first. That hasn't happened, so the manpage format
is still considered the "best" approach to create manual pages. (people
who want to use a different "viewer" can do so by setting environment
variables; some even do.)
The reason the markup is done the way it is has less to do with legacy
than it does with the "do one thing and do it well" approach to doing
things in Unix (after which Linux was modelled). Nroff/troff/groff and
related utilities are document formatting programs. They don't "care"
what the final display device will be, but rather do their thing on data
fed to them on input, and spit the result out their standard output.
That's why "more" (less on Linux) is used to provide a screen-by-screen
display. HTML-capable viewers are not particularly known for doing one
thing only, let alone doing it well.
You have repeatedly argued that this approach "echoes the M$ way of
imposing more complications than are necessary on the end user, ...."
I would argue that dumbing the system interface down to the point that
everything just looks like a web-page is EXACTLY the "M$ way of imposing
more complications than are necessary on the end user," under the guise
of superficially appearing simpler.
You make the argument that "Every little thing needing it's own app, with
it's own set of function keys, mindset. logics, flags, etc." is a form af
"app-creep", and that "a single killer-app", though not many would think
of the idea, is your vision. That sounds to me like going towards the
"M$ way of imposing" limitted flexibility on the end user. Some people
like the idea of sending a formatted manual page to a display device
other than their screen, by piping the standard output of the "man"
program to (for example only) lpr. You need to read the Lynx manual
page ("man lynx") to figure out how to do the same with Lynx ("lynx
-dump ... |lpr"). I have absolutely no idea how you might do the same
with, say Firefox as your HTML viewer.
You tell Jim Diamond to lay off the sarcasm, yet you tell Grant to "miss
a turn." Who's being sarcastic, hmmm?
My conclusion here is that you're not looking to actually solve any
specific problem, except perhaps that you have trouble grasping the idea
of "press the spacebar to see the next screenful". You appear to be
looking for an argument for its own sake. If you truly wanted to solve
the "why do manpages have their own format for which we need a specific
viewer" problem, you would already have created the necessary extensions
to an HTML viewer, such as lynx, and be proposing its use instead, even
if as a proof of concept.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Sylvain Robitaille
> Hypertext replaced Gopher? Damnation, why wasn't I told?!
> When did that happen, anyway?
When was the last time you accessed a Gopher server to find any
information? My bet is that it's been a while ...
Sylvain Robitaille
>>>> That's the problem with newbies: they want everything to be a web
>>>> page ...
>
> .... It was an assumption, and it was wrong.
I think the only assumption being made about the above statement is the
one you're making. It was an observation, perhaps even a
generalization, but not an assumption.
> T'were only a suggestion. There are other options. My point was that
> multi-use tools can do the same job. No need for a specialist reader
> with it's own special format and own special documentation.
The "special reader" used to display manual pages amounts to a
combination of a document formatter (which can do much more than format
manual pages for display), and a "pager" (whose purpose in life is to
display plain-text on its input, one screenful at a time). The "special
format" you refer to is used as much to typeset documents (in fact, I
believe that was its original purpose) as it is to markup manual pages
for display. This stuff is no more "specialist" or "single-purpose"
than HTML is or ever was. The only real difference at this point, is
that everyone and his dog knows how to create HTML, even if they need to
use a WYSIWYG interface to do it. The nroff/troff format doesn't
require any more specialized knowledge to create (or read) than HTML
does.
>> Why weren't you demanding answers to those very questions when
>> hypertext was threatening to replace Gopher???
>
> html is a better multi-purpose option.
You were sure of that in the mid-nineties? Frankly, I'm not sure of it
NOW.
> If somebody can't write up some development code to extend the functions
> of commonly used applications like file managers and html browsers, then
> we might as well sign up for Vasta. :(
If you've written the patches, I'm willing to apply them and try them
out ...
Beej Jorgensen
>Responding to Beej Jorgensen:
>> No, it would be XML. It definitely would not be HTML.
>
How's that? It looks like you were saying that having a "special"
reader (man) for an uncommon "special" format (troff) was unnecessary
when everyone had a web browser right there.
Instead, you proposed HTML, which is suboptimal because its not
necessarily XML, it uses a presentational tags, and it imposes no
consistent structure on the document. XHTML is better, but only because
it's XML.
Some well-defined XML and a CSS stylesheet seems like the near-perfect
solution for this issue.
* Works on 99% of all web browsers out there (even elinks supports it to
a certain extent--probably enough to render man pages)
* Uses logical tags instead of presentational tags; can add man-page
specific structure
* XML is even more general purpose than HTML, and is very easily
converted into other formats, including PDF or XHTML, by a zillion
tools in a zillion languages.
* Can be easily programatically updated for some changes in the XML spec
* Can be "skinned"
* Can be easily presented in different mediums and on different physical
page sizes.
* XML not locked to CSS for style--could still use XSL with same source
documents.
* The man command could be changed to support a small specialized XML
format much more easily than it could be changed to support HTML
Tables are a bit of a sticking point, but not impossible, I don't think.
-Beej
Loki Harfagr
> On Mon, 29 Sep 2008 10:25:22 +0000, Mike wrote:
>
>> I'm asking why this old way is still "the standard" and suggesting its
>> obsolete, only still there because of a cycle of old hands used to
>> using it, and newbies feeling as if they need to get up to speed with
>> it as if
>
> I already answered this in another post, but here it is again: Not all
> *nix systems have a web browser available for viewing man pages, n00b.
and even in the case there's one it's not the whole pie, half the
time I see html pages is under vi, I also tried vi on man pages and the
result was quite disapointing ;D)
of course that's with a real vi, not the vim-basquiatizer...
duck!
No_One
>>> "We've always done it this way" doesn't cut the mustard when you've
>>> jobs waiting and need to fix something before something else happens as
>>> a result.
>>
>> The man reader prevents you from completing jobs....is that your point
>> here?
>>
>> I love to "hear" the explanation for this piece of rubbish.
>>
>>
>>
>> ken
>
>
> You appear to be looking for a flame here, and I'm not.
>
>
You can't answer the question so you avoid it. The question is valid, how
does the man reader prevent you from completing jobs as claimed in your post.
Or are you just more interested in dealing with hyperbole to make a point
that logic prevents you from making....
ken
Mark Madsen
> Mark Madsen wrote:
>
>> Hypertext replaced Gopher? Damnation, why wasn't I told?! When did
>> that happen, anyway?
>
> When was the last time you accessed a Gopher server to find any
> information? My bet is that it's been a while ...
OK, I apologise. I left the <humour> tags off.
The honest answer in my case is, about 1994 or 1995 was the last time.
And before you ask, the last time I used Archie was sometime before that.
Michael Black
Then does emacs have built in man reading capability?
Michael
Sylvain Robitaille
>> When was the last time you accessed a Gopher server to find any
>> information? My bet is that it's been a while ...
>
> OK, I apologise. I left the <humour> tags off.
No apology necessary. I think the implied humour was quite suitable.
Nevertheless, my question stands ...
> The honest answer in my case is, about 1994 or 1995 was the last time.
I'm pretty sure I used the University of Minnesota's Gopher server more
recently than that (1996? 1997? maybe 1998?), but by that time it was
more out of curiosity regarding what was still there than that I
couldn't find what I was looking for otherwise.
> And before you ask, the last time I used Archie was sometime before
> that.
Now Archie I'm sure I was using as late as 1996. I really liked Archie
Thomas Overgaard
Sylvain Robitaille wrote :
> When was the last time you accessed a Gopher server to find any
> information?
Wonder if Veronica is still alive.
--
Thomas O.
This area is designed to become quite warm during normal operation.
Thomas Overgaard
Chick Tower wrote :
> Use Konqueror to read your man and info pages if you insist upon using a
> web browser to do so.
If it has to be graphic then IMHO khelpcenter is better.
Grant
>On Mon, 29 Sep 2008 07:49:58 -0500, Dan C sprout:
...
>> I already answered this in another post, but here it is again: Not all
>> *nix systems have a web browser available for viewing man pages, n00b.
>
>and even in the case there's one it's not the whole pie, half the
>time I see html pages is under vi, I also tried vi on man pages and the
>result was quite disapointing ;D)
>
>of course that's with a real vi, not the vim-basquiatizer...
>duck!
Does vi open .gz files like vim can? I like the colours in vim :)
Grant.
--
http://bugsplatter.id.au/
Michael Black
>
Chick Tower wrote :
>
>> Use Konqueror to read your man and info pages if you insist upon using a
>> web browser to do so.
>
> If it has to be graphic then IMHO khelpcenter is better.
Graphic man pages?
Michael
Grant
...
>Now Archie I'm sure I was using as late as 1996. I really liked Archie
1993, that year I moved out of Melbourne and didn't get direct Internet
(not that the shell type text only access was direct, had to use ftpmail
gateways to get files) again until it came to town in '95. Of course
then it was the web instead. Was on fidonet for a while via a local BBS.
Grant.
web site is on :8080 at the moment, port 80 somehow got isolated by ISP :(
--
http://bugsplatter.id.au/
Sylvain Robitaille
> Does vi open .gz files like vim can? ...
Which vi? There are different implementations.
Grant
>Grant wrote:
>
>> Does vi open .gz files like vim can? ...
>
>Which vi? There are different implementations.
On slackware? Is it elvis? In any case whatever slack-11 has for vi
is quite clever, rather than throw a conniption with a .gz it:
offset 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00000000 <1f>8b 08 00 47 20 cb 48 00 03 c5 5a eb 73 da d8 ....G ËH..ÅZësÚØ
00000010 92 ff ae bf a2 eb 4e 6d 5d 98 05 ac 37 a0 bb 99 .ÿ®¿¢ëNm]..¬7 ».
00000020 ba bc 9c 50 31 36 6b c8 64 76 b3 29 97 90 0e 46 º¼.P16kÈdv³)...F
went into hex edit mode, now there's something I didn't know ;)
Grant.
--
http://bugsplatter.id.au/
Jerry Peters
> Responding to Michael Black:
>
>> On Sun, 28 Sep 2008, Mike wrote:
>>
>>> Responding to Grant:
>>>
>>> [...]
>>>>>
>>>>> So, my question has evolved into...
>>>>>
>>>>> * Why do we need a specialist reader/format for basic information?
>>>>
>>>> a different breed of markup, that's all. Your argument is weak...
>>>
>>> So I CAN read them in my browser then, a tool that my fingers know
>>> instinctively, without having to read up on the reader I needed to read
>>> about something else? No... hang on... just tried it. It doesn't WORK
>>> that way! Dayam! I need a special reader to read those pages! :(
>>>
>> I just looked at a man page with lynx, and it displays fine, the only
>> difference being the lack of highlighting, which perhaps can be fixed
>> with some changes to a config file.
>
> Or, if the man pages themselves were html/html compatible... ?
>
>
>> I think, though, that you are arguing a false point. In the seven years
>> I've been using Linux (which means seven years of using Slackware), I've
>> never seen man as anything but invisible. It never gets in the way, it
>> just displays the man page without any fuss. Indeed, I don't even think
>> about how I'm invoking a command titled "man" and passing to it the
>> specific man page I want to read, I think of it as looking at the man
>> page for the thing I'm wanting to read.
>>
>> The man command is as invisible as cd or ls.
>>
>
> I understand that. I'm not arguing that. I'm looking specifically a the
> fact man pages are written to be primerily read by a special reader,
> dedicated to just that purpose, and thats not a very "Linux" way to do
> things compared to the extensible range of things other Linux apps can
> typically be called upon to do.
>
But it's _not_ a special reader. The man command searches the
directories it know about (via MANPATH) for a man page, then uses
troff to format it and less to display it. It's not a big monolithic
program as you seem to think. In fact, I'd say a web browser is more
un-Linux like, as it _is_ a large, monolithic program which does HTTP,
FTP, and displays images, among other things.
> Sure, a little ingenuity can fix things, convert the man pages, extend
> the capacity of a browser, but the basic setup is still the "old way".
>
> I'm asking why this old way is still "the standard" and suggesting its
> obsolete, only still there because of a cycle of old hands used to using
> it, and newbies feeling as if they need to get up to speed with it as if
> it is some kind of magic Linux thing, which it isn't, and only figuring
> out later than its function-specific legacy software, not something with
> supa-dupa functions nothing else can do. The fact its so ingrained and
> "traditional" in most/all distros is probably why its still there.
>
Because I can type "man bash" then search for what I'm interested in.
With HTML it'd be similiar to info, separate topics in separate
sections (usually different files), so I need to first find the
appropriate section, then search for my topic. I'll take man over that
any day.
Jerry
Jerry Peters
>
> Yeah, one can learn the intricacies of the man reader, but thats what I'm
> talking about. Its a form of "app-creep". Every little thing needing it's
> own app, with it's own set of function keys, mindset. logics, flags, etc.
> etc. etc.
I use "less" for reading plain text, too. It's not only for manpages.
>
> While the idea of a single killer-app might not appear to some/many, IMO
> the man reader thing is heading in the other direction, and in some ways
> echoes the M$ way of imposing more complications than are necessary on
> the end user, when there are simpler and more direct ways of delivering
> that content.
Let's see "man bash" as opposed to what? Man searches MANPATH, are you
going to implement that in the browser? Mostly I know which man page I
want, I just need to look up an option, or be sure I've remembered it
correctly. I _don't_ want to, or need to wade through a TOC to find
the page I'm looking for.
Again, man is not a single program, it's a pipeline. It could actually
be implemented as a shell script if someone wanted to code it. The
complicated part is finding the desired manpage, after that it's a
simple pipeline.
Jerry
>
>
>>> Be honest. If the man page format did not already exist, would anybody
>>> actually invent it today?
>> That's a good question, which probably none of us can answer
>> definitively. But people who aren't happy with the limitations of HTML
>> browsers might invent something else.
>
> Ok. Let me take a shot at it then. No. Nobody would write the man page
> reader as somebody else would have said "Hey! Lets use HTML if we need
> markup!" and somebody else would have said "Hey! Lets extend XYZ browser
> to give us bookmarking functions and other cool stuff!" and so on...
It pre-dates HTML by over a decade. Heck, I was using a predecessor
called runoff back in the late 60's.
>
> I propose that the ONLY real reason anybody uses the man page reader
> stuff is because its already there, and "we've always done it this way",
> plus, the subtle but "in there" defensive responses I'm seeing are
> typical of any suggestion of change being made to people who pride
> themselves in their skill with something.
No, because it's simple to use and it just works. It's resistance to
overly complex solutions to simple problems.
Jerry
No_One
> But it's _not_ a special reader. The man command searches the
> directories it know about (via MANPATH) for a man page, then uses
> troff to format it and less to display it. It's not a big monolithic
> program as you seem to think. In fact, I'd say a web browser is more
> un-Linux like, as it _is_ a large, monolithic program which does HTTP,
> FTP, and displays images, among other things.
>
Good point...I think the OP is missing that point and it's an important
point. In addition, the OP can install pinfo for man page use as well as
info page use and get the same keystroke commands available for lynx as well
as clickable links to other manpages.
The OP is turning a simple information solution into a complex issue.
ken
Keith Keller
>
man man2html
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Jim Diamond
> On 2008-09-29, Mike <N...@Arizona.Bay> wrote:
>>
>> Or, if the man pages themselves were html/html compatible... ?
>
> man man2html
Of course, now we are back at the beginning "problem", since some people
have a hard time using man :-)
Jim
No_One
Well, I'm guessing here, but the solution might be to convert the man page
for man2html to html so that it can be viewed in a browser -- for the
benefit of some.
ken
Sidney Lambe
A guy asks a harmless question, and the bozos on this group go on about it
for days.
Will he ever be back? I doubt it very much.
No wonder Slackware remains a minor distro. It's most obvious advocates are
a bunch of arrogant assholes clearly in need of lives.
Sid
Jim Diamond
> Responding to Jim Diamond:
>
>> On 2008-09-28 at 11:33 ADT, Mike <N...@Arizona.Bay> wrote:
>>> Yeah, I KNOW things can be converted/scripted/altered, but thats not
>>> the point of my question.
>>>
>>> Why do we need a special reader for specially formatted documentation
>>> at all?
>>
>> Maybe because it does a better job than using a web (oops, HTML)
>> browser?
>>
>> Can your HTML browser do regular expression searches?
>>
>> Can you set "bookmarks" at specific lines with your HTML browser so that
>> you can easily flip back and forth in the man page you are reading?
>>
>> Can you imagine that not everyone wants to use some piece of bloatware
>> every time they want to do something simple?
>
> Lynx is hardly bloatware. Lets get rid of the idea that Firefox is the
> only browser on the planet shall we?
So, do you think lynx is much more obvious and straightforward than
man? Does it not have its own arcane behavior? I assume most people
(at this point) know how to use something like firefox, because of all
the web sites which use graphics/images/movies/..., but I'm betting a
small percentage of people use text-only browsers like lynx.
> As for the functions you describe here, surely developing a browser to
> include these functions makes more sense than investing in a single-
> purpose reader application? (More on this further down.)
Who is investing what? It has been around since the 1970's?
In fact, to put those functions in a browser would require an
investment in time by someone now (as far as I know).
>>> This is a legacy thing, and I suppose I'm arguing that its not only
>>> obsolete, but arguably time consuming and distracting for today's Linux
>>> user base.
>> Your argument so far is very weak, please share some good points with
>> me, I'm always keen to know about better ways to do things.
> Sarcasm isn't helping here, and indicates a weak stance.
> Lets tip-toe away from the potential for a flaming as thats not what
> I'm seeking here.
There is no sarcasm or flaming there. Your argument as stated (so
far) is weak. And I am always interested in better/easier ways to do
things; if you are able to point out a better way of doing things, I
am genuinely interested.
So far all of your writing indicates a lack of understanding of what
the man program does for you. Maybe you do understand it, but your
messages don't suggest that to me.
>>> "We've always done it this way" doesn't cut the mustard when you've
>>> jobs waiting and need to fix something before something else happens as
>>> a result.
>> Does this have something to do with reading man pages?
> Sarcasm again. Lets leave that.
Again, no sarcasm.
>>> Or do we assume all Linux users go through a Linux Training Camp before
>>> being allowed near a live terminal? "If you have a problem you WILL
>>> read your man pages. IF you don't know all the tricks to using your man
>>> page reader you WILL have another problem. IF you have another problem
>>> you WILL NOT solve your first problem UNTIL you have learned to fly
>>> your man page reader upside down while making a cup of tea and
>>> compiling the latest X.org server in French! DO I MAKE MYSELF CLEAR
>>> MAGGOTS?" "SIR! YES SIR!"
>> Apparently you find your MANPAGER program (less, in my case) much more
>> difficult to use than most people. But really, it isn't that hard to
>> use it in a minimalist way. And if/when you come to the realization
>> that you want something that is more than minimalist, you will find that
>> there are other features to facilitate your man page reading.
> See above comments on investing in developing browser capacity rather
> than a single-purpose application.
> Yeah, one can learn the intricacies of the man reader, but thats
> what I'm talking about. Its a form of "app-creep". Every little
> thing needing it's own app, with it's own set of function keys,
> mindset. logics, flags, etc. etc. etc.
As other people have pointed out to you, the interface one normally
sees to reading man pages is "less", which is a program many people
use for viewing all sorts of text data, not just man pages.
> While the idea of a single killer-app might not appear to some/many, IMO
> the man reader thing is heading in the other direction,
It's not heading anywhere, if by "heading" you mean how its
development is proceeding. It's a mature piece of software.
> and in some ways echoes the M$ way of imposing more complications
> than are necessary on the end user, when there are simpler and more
> direct ways of delivering that content.
If you could articulate how you think using any existing HTML browser
is more convenient for viewing man pages than man is, I'd be very
interested.
>>> Be honest. If the man page format did not already exist, would anybody
>>> actually invent it today?
>> That's a good question, which probably none of us can answer
>> definitively. But people who aren't happy with the limitations of HTML
>> browsers might invent something else.
> Ok. Let me take a shot at it then. No. Nobody would write the man
> page reader as somebody else would have said "Hey! Lets use HTML if
> we need markup!" and somebody else would have said "Hey! Lets extend
> XYZ browser to give us bookmarking functions and other cool stuff!"
> and so on...
Rubbish. The items I mentioned above (regexp search, easy creating
and access of "bookmarks" inside one document/web page) would be
useful for things other than man pages, and yet (AFAIK) they aren't
there.
> I propose that the ONLY real reason anybody uses the man page reader
> stuff is because its already there, and "we've always done it this way",
> plus, the subtle but "in there" defensive responses I'm seeing are
> typical of any suggestion of change being made to people who pride
> themselves in their skill with something.
yes, there are some people who would rather use something they know
than change to using something new, but there is no point in changing
from a better system to a worse system, just for the sake of change.
But if/when someone comes up with a system which is better, people
will adopt it.
> I'm suggesting that the time to rethink things regarding the man page
> reader thing is not only here, but has been for some time.
Well, if you want it re-thought, I suppose you have two possibilities:
(1) rethink it thoroughly yourself and propose a solution, or
(2) convince someone else that it is worth it for them to rethink it
and propose a solution.
Judging by the other posts in this thread, I don't think you've said
anything to convince anyone else here. But who knows, maybe you will
in your next message.
Cheers.
Jim
Dan C
> A guy asks a harmless question, and the bozos on this group go on about
> it for days.
>
> Will he ever be back? I doubt it very much.
We can hope not, anyway. How about you disappear too?
> No wonder Slackware remains a minor distro. It's most obvious advocates
> are a bunch of arrogant assholes clearly in need of lives.
Now you're sounding like ANC, "Sidney".
> Sid
You're name is "Alan Connor", or "Tom Newton", you pathetic fucking
whacko. Get along and find your medication before you're committed again.
--
"Sidney Lambe" ("Tom Newton") - the latest nymshift of "Alan Connor".
Read more about the netkook Alan Connor here:
http://www.pearlgates.net/nanae/kooks/ac/fga.shtml
Email him: calh...@gmail.com or simple...@gmail.com
Mark Madsen
>> No wonder Slackware remains a minor distro. It's most obvious advocates
>> are a bunch of arrogant assholes clearly in need of lives.
>
> Now you're sounding like ANC, "Sidney".
And I seem to have read all that stuff about Slackware already:
Mike
[...]
>
>> While the idea of a single killer-app might not appear to some/many,
>> IMO the man reader thing is heading in the other direction, and in some
>> ways echoes the M$ way of imposing more complications than are
>> necessary on the end user, when there are simpler and more direct ways
>> of delivering that content.
>
> Let's see "man bash" as opposed to what? Man searches MANPATH, are you
> going to implement that in the browser? Mostly I know which man page I
> want, I just need to look up an option, or be sure I've remembered it
> correctly. I _don't_ want to, or need to wade through a TOC to find the
> page I'm looking for.
>
> Again, man is not a single program, it's a pipeline. It could actually
> be implemented as a shell script if someone wanted to code it. The
> complicated part is finding the desired manpage, after that it's a
> simple pipeline.
>
From where I'm sitting, you just outlined something I've been talking
about. Sure, issuing "man something" gets you documentation, but not in
any way that couldn't be done in several other ways. Sure, the obscure
and specialist formating can be piped into several other options. Sure,
its all learnable, and sure, its a process thats been developed and
smoothed over the years.
But its still specific formating that requires a specific process.
--
*===( http://principiadiscordia.com/
*===( http://www.badphorm.co.uk/
*===( http://www.zenwalk.org/
Mike
[...]
>>>
>>> Can you imagine that not everyone wants to use some piece of bloatware
>>> every time they want to do something simple?
>>
>> Lynx is hardly bloatware. Lets get rid of the idea that Firefox is the
>> only browser on the planet shall we?
> So, do you think lynx is much more obvious and straightforward than man?
Not in the slightest. I was simply offering a preliminary example that
could be seen as a developable option, rather than heading off down the
road of specific single-purpose applications/processes.
I'm not waving a flag here shouting "Do things my way!", I'm simply
looking at something I tripped over and found to be one of those things
one rarely questions, and appears to be the product of having rarely been
questioned. If somebody was to start inventing an operating system right
about now, the way man pages are stored and delivered wouldn't be re-
invented. Maybe some of the functions provided by the current setup
would, but not the exclusive restricted and, I have to say it coz thats
how I see it, dead-end formatting.
[...]
>
>> Yeah, one can learn the intricacies of the man reader, but thats what
>> I'm talking about. Its a form of "app-creep". Every little thing
>> needing it's own app, with it's own set of function keys, mindset.
>> logics, flags, etc. etc. etc.
> As other people have pointed out to you, the interface one normally sees
> to reading man pages is "less", which is a program many people use for
> viewing all sorts of text data, not just man pages.
>
>> While the idea of a single killer-app might not appear to some/many,
>> IMO the man reader thing is heading in the other direction,
> It's not heading anywhere, if by "heading" you mean how its development
> is proceeding. It's a mature piece of software.
Its a /legacy/ piece of software. If it's not "heading", as in "being
developed/maintained" then its also potentially obsolete. (Just a thought
there, nothing more. ;)
Mature, yes, in common use, yes, even prefered by those who are familiar
with it, but to suggest that its "maturity" is an indication of it's god-
like design (OTT? ;), or that maturity itself is the indicator of "how
things should be done" is surely stretching things a tad.
If it were that clever and efficient, many other things would work just
like it, but don't. Its unique. It has it's own logics and
idiosyncracies, and adds to a list of unique interfaces the Linux user
needs to become familiar with, without offering anything particularly
better than other multi-purpose ways of doing the same jobs.
IOW, its clutter. Friendly, familiar, maybe even prefered by those who
have spent the time getting to know it, but its a cul-de-sac. It does
nothing else, and other things can do what it does. Maybe not as well,
ATM, but thats surely because there has always been the fallback that it
is easier to learn the (old) man reader way than write a new function
into a file manager or browser.
[...]
>
>> I'm suggesting that the time to rethink things regarding the man page
>> reader thing is not only here, but has been for some time.
> Well, if you want it re-thought, I suppose you have two possibilities:
> (1) rethink it thoroughly yourself and propose a solution, or (2)
> convince someone else that it is worth it for them to rethink it
> and propose a solution.
Already considered. If I had the time and dexterity (not to mention the
eyesight) I might have considered giving it a go, just for the learning
experience if nothing else, but all I can do these days is raise the
question and hope somebody either points out what I've missed, or picks
up on the idea. As man2html and man2text already exist, I guess I'm not
alone in at least some of my experience/opinion here. :)
> Judging by the other posts in this thread, I don't think you've said
> anything to convince anyone else here. But who knows, maybe you will in
> your next message.
I'm not trying to "convince" anybody of anything. Nor am I seeking to
make anybody who finds thing to be different to how I'm seeing them feel
less. All I'm trying to do is examine something I think has become
entrenched in a "We've always done things this way" rut. So far, I've
seen quite a bit of the kind of response this situation would generate.
What I would like is to look at the options, and instead of saying
"T'aint gonna happen buddy!" or "If ya think yer so clever, do it and
we'll letcha know!", and maybe find a few "How else could this be done?"
ideas.
Mike
(Caught this coz you replied to it.)
Is that blusting idiot Dan C still trying to haunt people who plonked him
years ago? Is that tenacity, or insanity? ;)
Don't bother Dan. You ain't getting out any time soon. :)
Mike
That'd be me, and yes, I run the risk of doing just that.
The problem I'm having with a number of replies, however, is that my
suggestion that other ways of doing this are not only possible, but
practical, are seemingly refuted by comparisons with how things are right
now. For example, I suggest using Lynx, and instead of actually examining
this idea and suggesting development options, or an alternative, the
typical response is "Can't do it the same, got used to this way now,
forget it."
Sure there are task specific functions the man reader process can do
better than a browser that was never designed or developed in that
direction, but it /could/ be, and /wasn't/.
So, its maybe not so much me turning things into a complex issue, but
that the question itself involves complexity that is already there, is
traditionally avoided as its easier to just learn to use the man reader
process, and this needs to be waded through if one is to examine the
question I'm looking at.
IOW, the existence of the traditional man reader process has acted as a
diversion to development of a potentially better way of integrating
system and other documentation into other multi-purpose/function
applications.
P.S. OP = Mike. Hi there! :)
Mike
Yoohoo! Over here! The point is way over here guys!
Damn! Too far away. They'll never hear me at this distance. :(