473,326 Members | 1,972 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Displaying code with <pre>

I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash shell pieces like this:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com&lt; &lt;EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF
</code></pre>
</p>

If I leave the << to indicate I am using a Here document, then the WDG
validator complains about all sorts of stuff.

If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.

If I add a space between the two &lt; &lt; the code shows, but the use
of the double << for a Here document isn't clearly shown.

Live page is at http://ericlindsay.com/blog/200508.htm#5 and will show
one of the three problems.

Can anyone straighten out my thinking on this?

--
http://www.ericlindsay.com
Dec 30 '05 #1
9 5515
Eric Lindsay <NO**********@ericlindsay.com> wrote:
If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.

If I add a space between the two &lt; &lt; the code shows, but the use
of the double << for a Here document isn't clearly shown.

Live page is at http://ericlindsay.com/blog/200508.htm#5 and will show
one of the three problems.


Must be a bug in your browser, works fine here in my (Windows) browsers
Opera, IE6, FF, Moz.

http://homepage.ntlworld.ie/spartanicus/temp.htm

--
Spartanicus
Dec 30 '05 #2
In article <NO********************************@freenews.iinet .net.au>,
Eric Lindsay <NO**********@ericlindsay.com> wrote:
I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash shell pieces like this:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com&lt; &lt;EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF
</code></pre>
</p>


This displays fine in Safari and validates by BBEdit:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head><title></title></head>
<body>
<pre>
<code>
#!/bin/sh
ftp -i -n ftp.server.com&lt;&lt;EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF
</code>
</pre>
</body>
</html>

It didn't work worth a damn when I wrapped it in a <p> element which I
assume you did judging by the </p> at the end of your example. And I
know that there is a reason for it, but it's 4 AM and I'm sleepy. Note
that I eliminated the extra space between the &lt; entities.
Hope this works for you, and I know you will be told definitively why
your original example didn't work.

leo

--
<http://web0.greatbasin.net/~leo/>
Dec 30 '05 #3
Eric Lindsay wrote:
I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash shell pieces like this:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com&lt; &lt;EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF
</code></pre>
</p>

If I leave the << to indicate I am using a Here document, then the WDG
validator complains about all sorts of stuff.

If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.

If I add a space between the two &lt; &lt; the code shows, but the use
of the double << for a Here document isn't clearly shown.

Live page is at http://ericlindsay.com/blog/200508.htm#5 and will show
one of the three problems.

Can anyone straighten out my thinking on this?

Yes, it truncates to this on Mozilla in Slackware:
#!/bin/sh
ftp -i -n ftp.server.com <

....truncating after that first <.

Since Spartanicus and L. Blaisdell can't see it,
I think it's something specific to browser decoding.
I use <pre> a lot, and that's something I havn't run into
before.

I downloaded it and played with it a bit. The thing that
brings it back under Moz/Slack is using &lt;&lt;, as you
predicted. I suspect you'll just have to live with WGD's
complaint, but both > characters display under Moz. What
browser are you using that displays it only as a single >?

The other problem is that under Moz/Linux, the newlines you are
using inside the <pre> do not show up in the Moz display.
I had to go in with vim and add the newlines myself to get
the lines to display in the <pre> correctly.
--
mbstevens
http://www.mbstevens.com/howtothumb


Dec 30 '05 #4
Fri, 30 Dec 2005 20:55:36 +1000 from Eric Lindsay <NOSPAmar2005
@ericlindsay.com>:
If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.


I do see that problem with Mozilla 1.7x under Windows XP. But when I
look at source this is what I see:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com &lt;<eof user="" username="" password=""
epsv4="" cd="" lcd="" ~/documents/web101="" put="" test.htm=""
quit="" eof=""></eof></code></pre>

I have no idea what <eof> is supposed to be, but it's certainly not a
valid tag.

It's not just Mozilla; lynx shows me a variation on the same thing
(with line breaks between the attributes).

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Dec 30 '05 #5
In article <VI*****************@newsread2.news.pas.earthlink. net>,
mbstevens <NO***********@xmbstevensx.com> wrote:
Eric Lindsay wrote:
I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash shell pieces like this:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com&lt; &lt;EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF
</code></pre>
</p>

If I leave the << to indicate I am using a Here document, then the WDG
validator complains about all sorts of stuff.

If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.

If I add a space between the two &lt; &lt; the code shows, but the use
of the double << for a Here document isn't clearly shown.

Live page is at http://ericlindsay.com/blog/200508.htm#5 and will show
one of the three problems.

Can anyone straighten out my thinking on this?
Yes, it truncates to this on Mozilla in Slackware:
#!/bin/sh
ftp -i -n ftp.server.com <

...truncating after that first <.

Since Spartanicus and L. Blaisdell can't see it,
I think it's something specific to browser decoding.
I use <pre> a lot, and that's something I havn't run into
before.

I downloaded it and played with it a bit. The thing that
brings it back under Moz/Slack is using &lt;&lt;, as you
predicted. I suspect you'll just have to live with WGD's
complaint, but both > characters display under Moz. What
browser are you using that displays it only as a single >?

The other problem is that under Moz/Linux, the newlines you are
using inside the <pre> do not show up in the Moz display.
I had to go in with vim and add the newlines myself to get
the lines to display in the <pre> correctly.


I can see the problem when I view it in Firefox. But when I
view the page source, I am not seeing any &lt;s, only <'s:

<pre><code>
#!/bin/sh
ftp -i -n ftp.server.com <<EOF
user username password
epsv4
cd /
lcd ~/Documents/web101
put test.htm
quit
EOF</code></pre>


Lynx -source shows pretty much the same thing, but without the
">" before the </code>. So Firefox is interpreting everything
from the <EOF to that > an unrecognized tag.

--
= Eric Bustad, Norwegian Bachelor Programmer
Dec 30 '05 #6
Eric Lindsay <NO**********@ericlindsay.com> wrote:
ftp -i -n ftp.server.com&lt; &lt;EOF
That's correct markup and works well, though it represents
ftp -i -n ftp.server.com< <EOF
which is not what you mean. Use
ftp -i -n ftp.server.com &lt;&lt;EOF
instead (i.e., move the space after the first &lt; before it).
If I leave the << to indicate I am using a Here document, then the WDG
validator complains about all sorts of stuff.
Of course you must not write the "<" characters as such but e.g. "escape"
them as &lt;. If you use them as such, <EOF will be parsed as starting a tag.
("Escaping" the first "<" isn't strictly necessary in HTML 4.01, but
surely a good idea.)
If I use adjoining &lt;&lt; with no space, then the first < displays,
but the rest of the code example disappears.
That would be nasty bug in a browser, but we could probably find a workaround
rather easily (using dummy markup, such as &lt;<span>&lt;</span>, might
help). So far, I can see no direct evidence of such a bug. I just tried on
Firefox 1.0.2, and it shows &lt;&lt; correctly as <<.
If I add a space between the two &lt; &lt; the code shows, but the use
of the double << for a Here document isn't clearly shown.
Then there is no "<<" but "< <". That would be a poor workaround to a bug,
but I don't think there _is_ a bug.
Live page is at http://ericlindsay.com/blog/200508.htm#5 and will show
one of the three problems.


Well, it contains invalid markup, with <<EOF, so it is guaranteed to be
wrong.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Dec 30 '05 #7
Thank you for the many interesting replies, and for helping me see the
problems with using <pre>

The example Spartanicus provided works fine in Safari, although my own
web page does not. My own page also failed in Opera and Firefox.

Leonard Blaisdell probably put his finger on the problem, with the
comment about it not working worth a damn when he wrapped it in a <p>
element. Basically none of my HTML has ever included the (optional)
closing elements for list items or paragraphs. However as part of this
cleanup, I added them. Previously <pre> would have signalled closing of
the previous <p> block element, but now there is a </p> at the end of
the </pre>.

However, finding the <pre> problem came when I had just organised bulk
validation of an entire directory. It is entirely possible that I
changed the pages in question in other ways while correcting other
errors or problems. For example, I did a global addition of </p> to all
paragraphs, however my search for a typical paragraph did not cover all
possibilities, and also added </p> at inappropriate places.

Eric Bustad sees a > prior to </code> that isn't in my source.

MB Stevens raises the point that the new lines I am using inside <pre>
do not show up under Moz/Linux. This gets even more confusing when Stan
Brown reports the source code appearing to him as absolutely nothing
like what I wrote. I have no idea where the ="" that he sees come from.
The eof is simply an unusual word used as the starting point and end
point for a Here document in Bash. It was never intended to show as a
tag.

However both of these point to a serious problem with using <pre> to
show any text that depends on new lines. Bash shell scrips do depend on
new lines. So now I am scratching my head wondering where new lines
went wrong.

My web pages were housed on Unix, where 0x0A ^J or Line Feed (called New
Line and '\n' in C) ends a line.

My pages lived on MS-DOS for many years, where both Carriage Return 0x0D
^M and Line Feed 0x0a ^J are used together.

My pages have now been moved to a Macintosh. Editors seem to be moving
from old Macintosh line endings of 0x0D ^M Carriage Return alone used on
Apple II and through to Mac OS 9. Now Macintosh editors seem to be
moving to just an 0x0A Line Feed. To make this much worse, I have been
editing my pages with a wide variety of editors, while trying to find an
editor I like. I am no longer even sure what treatment has been applied
to any particular file. (Hmm, no man page for hexdump or od - surely a
Macintosh has some sort of file dump?)

Finally, RFC2616 seems to be saying "HTTP/1.1 defines the sequence CR LF
as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7."

Section 3.7.1 says "When in canonical form, media subtypes of the "text"
type use CRLF as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP."

So it is entirely possible that some of my files have inconsistent
treatment of the line break that I don't know about. This is just
getting more and more wonderful by the minute!

Jukka Korpela correctly points out that I am totally wrong in ever
allowing any < character to get into the <pre> in the first place.

My conclusions. Please feel free to disagree and point out better ideas.

1. <pre> does not work well enough to be used for displaying anything
where line break is significant. That means not using it for code or
poetry.

2. Cutting and pasting code into <pre> was an error - I am going to
fail to notice characters that should be escaped. I should make a
little shell script to turn code snippets longer than a single line into
correct HTML. Specifically, the script should target < > and & and turn
them into character entities (is there anything else to target?)

3. I could use <p><code>Content<br>
&nbsp;&nbsp;more content&lt;&lt;<br>
</code></p> and style <code> with CSS.

That seems very messy to me, especially the use of multiple &nbsp;
however I can't see many alternatives at the moment.

I could use <pre><code>Content<br>
more content&lt;&lt;<br>
</code></pre>
This assumes <pre> will get white space correct, but fail to get line
breaks OK. If it does get line breaks, then double lines are used,
unless I send the code as one long line of text with no line breaks at
all.

Hmm, or I could enclose every line of every example in its very own
<pre><code> pair (which solves the white space problem) , and use CSS to
reduce the space between each line!
<pre><code>content</code></pre>
<pre><code> content2</code></pre>
<pre><code> content3</code></pre>

That should present OK on any modern browser. Better suggestions would
be most welcome.

--
http://www.ericlindsay.com
Dec 31 '05 #8
Eric Lindsay <NO**********@ericlindsay.com> writes:
The example Spartanicus provided works fine in Safari, although my own
web page does not. My own page also failed in Opera and Firefox.
As fascinating as it might be at your end, please provide standalone
test cases for all the failing scenarios.
So it is entirely possible that some of my files have inconsistent
treatment of the line break that I don't know about. This is just
getting more and more wonderful by the minute!
I've got files edited on Windows, Linux, OS 8 and OS X as well.
Whatever the particular OS convention, a text editor should be
(and usually is) configurable how to treat end of lines. Frankly I
never cared, because for publishing on the web FTP converts them to the
target file system anyway (assuming ASCII mode).
Jukka Korpela correctly points out that I am totally wrong in ever
allowing any < character to get into the <pre> in the first place.
That's not entirely what he said. You can have tags in a PRE element,
and *syntactically* '<' is only STAGO if followed by a name start
character (for HTML [a-zA-Z]). It's just _safe_ to always use an escape
notation (just as with '>' which *never* needs it) because HTML has
nothing to do with SGML in the first place (the only possible
encounter of the 3rd kind is the futile exercise of type validation).
1. <pre> does not work well enough to be used for displaying anything
where line break is significant.
Maybe. Please demonstrate.
That means not using it for code or
poetry.


Psst.
AAAAAAAAAAAARRRRRRGH!!!!!!!!!!
Sorry, but poetry is not about *line breaks*. It's about *lines*.
That's a world of a difference, once you decide to care (on a more
pragmatic and on-topic level, headings (<H[1-6]>) do not suffice to mark
up sections either, *maybe* the start, never the end; likewise, <BR>
isn't _descriptive_ ['this is a line' => <line>some line</>], it's
_procedural_ [*do* somehing _here_ => <? break it>].
--
Good-bye, and keep cold
Dec 31 '05 #9
In article <m2************@email.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
As fascinating as it might be at your end, please provide standalone
test cases for all the failing scenarios.
I can no longer generate a failing test case, whether valid or (hidden
in comments) invalid. I now have no idea what I was looking at last
night that I can no longer see or reproduce. Must be user error on my
part, with only the case of <<text failing. Sorry. I had corrected
so many other errors I was probably punch drunk at the time.
http://www.ericlindsay.com/testthis/pretest.html
I've got files edited on Windows, Linux, OS 8 and OS X as well.
Whatever the particular OS convention, a text editor should be
(and usually is) configurable how to treat end of lines.
vi shows files dating back to March with inconsistent end of line
treatment, so at least some of the editors I used (I was testing around
20 different editors) were retaining existing line endings. Some (in
head) probably came from cut and paste from old Windows files. Some
were obviously transferred from my PDA. It appears the system TextEdit
silently retains existing line endings. Luckily Smultron and Text
Wrangler can both be configured to revert them to Unix.
Frankly I
never cared, because for publishing on the web FTP converts them to the
target file system anyway (assuming ASCII mode).


Can't use ASCII, have to use binary. I also have to toggle epsv4. I
recall having problems finding a combination that worked for ftp with
the web host I am using. The arrival of computers that "just work" seem
to be receding faster than my hairline.
Jukka Korpela correctly points out that I am totally wrong in ever
allowing any < character to get into the <pre> in the first place.


That's not entirely what he said. You can have tags in a PRE element,
and *syntactically* '<' is only STAGO if followed by a name start
character (for HTML [a-zA-Z]).


Thanks for the correction. However unless I want to elaborate the tests
I make when creating a <pre> then the easiest way out is not to allow
the characters & < or > inside it? I am utterly uninterested in having
to write workarounds. Doing correct (or even valid) HTML is rapidly
becoming more work than is worthwhile for the probable marginal gains.
1. <pre> does not work well enough to be used for displaying anything where line break is significant.


Maybe. Please demonstrate.


If people using any browser complain they are not seeing line breaks,
then the purpose for which I used <pre> is null and void. If I thought
it might work I'd just remove every confounded <pre> (there are probably
only a dozen or so in my pages) and provide a link to a text file
instead.

I can see why 95% of the people putting content on the web don't care
whether their content is valid, invalid, or written in crayon. After 15
years of the web being there, I seem further than ever from just being
able to buy a tool that will create standards based web pages that work
for most people.

I think I will wish you folks a happy new year, and go out and watch the
fireworks!

--
http://www.ericlindsay.com
Dec 31 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Matt Adams | last post by:
I want to move the following <PRE> defintion to a css file: <TABLE><TR><TD><PRE>sample text</PRE></TD> <TD> not predefined font</TD></TR></TABLE> should be <TABLE><TR><TD class=aaa>sample...
1
by: Alan Illeman | last post by:
This is one of several macros I wish to display: <PRE CLASS="special macro> ;; ;; Reverse argument list ;; reverse_args MACRO arglist:req local txt, arg txt textequ <> % FOR arg, <arglist>
3
by: Michael Shell | last post by:
Greetings, Consider the XHTML document attached at the end of this post. When viewed under Firefox 1.0.5 on Linux, highlighting and pasting (into a text editor) the <pre> tag listing will...
5
by: Porthos | last post by:
I'm authoring an XML document and using the <pre> html tag for the portions that are not dynamically generated. The <pre> text is displaying in a smaller font size (and I believe different font)...
7
by: Rocky Moore | last post by:
I have a web site called HintsAndTips.com. On this site people post tips using a very simply webform with a multi line TextBox for inputing the tip text. This text is encode to HTML so that no...
6
by: TomB | last post by:
Hello all, On the page located at http://deimos.curious.be/~dusk/lyrics.php#gotn I have put the lyrics text inside <pre> elements so that the UA renders the linebreaks in the code. Because...
14
by: Schraalhans Keukenmeester | last post by:
I am building a default sheet for my linux-related pages. Since many linux users still rely on/prefer viewing textmode and unstyled content I try to stick to the correct html tags to pertain good...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.