Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235011 > unrolled thread

Re: generate a rss.xml from a bunch of HTML files

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: generate a rss.xml from a bunch of HTML files Dan Ritter <dsr@randomstring.org> - 2021-05-09 13:50 +0200
    Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 15:30 +0200
      Re: generate a rss.xml from a bunch of HTML files Darac Marjal <mailinglist@darac.org.uk> - 2021-05-10 09:20 +0200
        Re: generate a rss.xml from a bunch of HTML files Dan Ritter <dsr@randomstring.org> - 2021-05-10 12:20 +0200
      Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 18:30 +0200
      Re: generate a rss.xml from a bunch of HTML files Dan Ritter <dsr@randomstring.org> - 2021-05-09 19:10 +0200
        Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 20:20 +0200
          Re: generate a rss.xml from a bunch of HTML files Dan Ritter <dsr@randomstring.org> - 2021-05-09 21:40 +0200
            Re: generate a rss.xml from a bunch of HTML files The Wanderer <wanderer@fastmail.fm> - 2021-05-09 23:40 +0200
              Re: generate a rss.xml from a bunch of HTML files Charles Curley <charlescurley@charlescurley.com> - 2021-05-10 01:30 +0200
                Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-10 01:50 +0200
                  Re: generate a rss.xml from a bunch of HTML files Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-10 08:10 +0200
                    Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-10 15:10 +0200
                      Re: generate a rss.xml from a bunch of HTML files Jonathan Dowland <jon+debian-user@dow.land> - 2021-05-12 12:50 +0200
              Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-10 01:50 +0200
              Re: generate a rss.xml from a bunch of HTML files Dan Ritter <dsr@randomstring.org> - 2021-05-10 12:20 +0200
                Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-10 15:20 +0200
          Re: generate a rss.xml from a bunch of HTML files Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-10 08:10 +0200
            Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-10 15:10 +0200
    Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 14:30 +0200
      Re: generate a rss.xml from a bunch of HTML files Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-09 15:10 +0200
    Re: generate a rss.xml from a bunch of HTML files Emanuel Berg <moasenwood@zoho.eu> - 2021-05-09 14:30 +0200

Page 1 of 2  [1] 2  Next page →

#235011 — Re: generate a rss.xml from a bunch of HTML files

Emanuel Berg wrote: 
> How can I generate a rss.xml from a bunch of HTML files?
> 
> Tho one would think this to be quite a simple tool of parsing
> the HTML and outputting the RSS XML dialect, I can't find any
> tool...
> 
> tt-rss maybe, but when I install it it tries to setup a MySQL
> database which fails.

That's a web-based RSS reader, not a generator.

> I don't know why, but it seems too involved anyway, there
> isn't a webpile2rss tool like this or something:
> 
>   $ webpile2rss *.html > rss.xml # sweet

There isn't one packaged in Debian, but there are libraries
packaged which would allow you to build one.

You might be happy with a static site generator, which takes a
directory full of documents and arranges them into a website,
usually including an RSS or ATOM feed.

Packaged in Debian:

hugo, jekyll, lektor, nanoc, staticsite, pelican

-dsr-

[toc] | [next] | [standalone]

#235013

Andrei POPESCU wrote:

>> ... no one did it? :O
>
> In FLOSS this usually means nobody else needed it.

Impossible in this, basic case. The static generator guys who
also did the RSS as mentioned already needed it, and did it,
only not modular to fit this purpose (IIUC from reading here).

> Why do you need it? Maybe we can suggest other means to
> achieve your (true) goal.

True goal!

I have a blog [1], just a bunch of HTML5/CSS files, absolutely
nothing advanced, and I'd like an RSS file [2] which is
generated from the HTML files (not the CSS, so even simpler
actually) so I for example can submit it here [2] and read it
with Gnus :)

So one needs a parser to parse the HTML, dispose of
unnecessary stuff, walk the tree (ha) and output it as
an RSS file.

Then I can have a Makefile to update the RSS file if and when
I do changes and add more posts.

[1] https://dataswamp.org/~incal/blog
[2] http://gwene.org

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235021

[Multipart message — attachments visible in raw view] — view raw

On 10/05/2021 07:06, Andrei POPESCU wrote:
> On Lu, 10 mai 21, 01:44:32, Emanuel Berg wrote:
>> Charles Curley wrote:
>>
>>> Right. However, as I found out asking elsewhere, you can
>>> include HTML in Markdown.
>> Hehehe, let's see, first write HTML, then include it in
>> Markdown, then have the static site generator generate
>> HTML... brilliant :)
> Surely there must be some site generator with RSS support that takes 
> "plain" HTML as input.

I would guess that there isn't, purely because the task of figuring out
what information to extract is relatively awkward. OK, there are some
easy tasks such as "What is the title of the page?" (<title> tag), "What
is the publication date of the page?" (mtime of the file), but there are
trickier questions: "Who was the author of this page?" (well, we could
hope for a meta tag, and fall back to the user running the tool,
perhaps) and "What's the copyright of the page?" (I'm fairly certain
there's no standard tag for that in HTML). Finally, there comes to the
tricky bit of the page summary. Most feeds provide a summary of the page
content to entice readers to read the whole article; one or two
paragraphs should be sufficient. But if you've ever used the "Reader
Mode" of a web browser, or ever pointed a screen reader at a web page,
you'll know that finding the body of the page isn't a 100% accurate task.

This is why so many site generators prefer you to provide the pieces and
they'll build up the final HTML. HTML *is* supposed to be a semantic
language rather than a presentation language (that is, one could argue
that the first few <p> tags are the first few paragraphs of the page),
but if you're asking for a tool that can parse arbitrary HTML
(including  machine-generated HTML), then I don't think it's going to be
easy.

>
> Kind regards,
> Andrei

[toc] | [prev] | [next] | [standalone]

#235058

Darac Marjal wrote: 
> 
> On 10/05/2021 07:06, Andrei POPESCU wrote:
> > On Lu, 10 mai 21, 01:44:32, Emanuel Berg wrote:
> >> Charles Curley wrote:
> >>
> >>> Right. However, as I found out asking elsewhere, you can
> >>> include HTML in Markdown.
> >> Hehehe, let's see, first write HTML, then include it in
> >> Markdown, then have the static site generator generate
> >> HTML... brilliant :)
> > Surely there must be some site generator with RSS support that takes 
> > "plain" HTML as input.
> 
> I would guess that there isn't, purely because the task of figuring out
> what information to extract is relatively awkward. OK, there are some
> easy tasks such as "What is the title of the page?" (<title> tag), "What
> is the publication date of the page?" (mtime of the file), but there are
> trickier questions: "Who was the author of this page?" (well, we could
> hope for a meta tag, and fall back to the user running the tool,
> perhaps) and "What's the copyright of the page?" (I'm fairly certain
> there's no standard tag for that in HTML). Finally, there comes to the
> tricky bit of the page summary. Most feeds provide a summary of the page
> content to entice readers to read the whole article; one or two
> paragraphs should be sufficient. But if you've ever used the "Reader
> Mode" of a web browser, or ever pointed a screen reader at a web page,
> you'll know that finding the body of the page isn't a 100% accurate task.
> 
> This is why so many site generators prefer you to provide the pieces and
> they'll build up the final HTML. HTML *is* supposed to be a semantic
> language rather than a presentation language (that is, one could argue
> that the first few <p> tags are the first few paragraphs of the page),
> but if you're asking for a tool that can parse arbitrary HTML
> (including  machine-generated HTML), then I don't think it's going to be
> easy.


Again, from the basic Pelican documentation, in the section
right after INSTALL:

---

Pelican interprets the HTML in a very straightforward manner,
reading metadata from meta tags, the title from the title tag,
and the body out from the body tag:

<html>
    <head>
        <title>My super title</title>
        <meta name="tags" content="thats, awesome" />
        <meta name="date" content="2012-07-09 22:28" />
        <meta name="modified" content="2012-07-10 20:14" />
        <meta name="category" content="yeah" />
        <meta name="authors" content="Alexis Métaireau, Conan
Doyle" />
        <meta name="summary" content="Short version for index
and feeds" />
    </head>
    <body>
        This is the content of my super blog post.
    </body>
</html>

With HTML, there is one simple exception to the standard
metadata: tags can be specified either via the tags metadata, as
is standard in Pelican, or via the keywords metadata, as is
standard in HTML. The two can be used interchangeably.

Note that, aside from the title, none of this content metadata
is mandatory: if the date is not specified and DEFAULT_DATE is
set to 'fs', Pelican will rely on the file’s “mtime” timestamp,
and the category can be determined by the directory in which the
file resides. For example, a file located at
python/foobar/myfoobar.rst will have a category of foobar. If
you would like to organize your files in other ways where the
name of the subfolder would not be a good category name, you can
set the setting USE_FOLDER_AS_CATEGORY to False. When parsing
dates given in the page metadata, Pelican supports the W3C’s
suggested subset ISO 8601.

So the title is the only required metadata. If that bothers you,
worry not. Instead of manually specifying a title in your
metadata each time, you can use the source content file name as
the title. For example, a Markdown source file named Publishing
via Pelican.md would automatically be assigned a title of
Publishing via Pelican. If you would prefer this behavior, add
the following line to your settings file:
---

[toc] | [prev] | [next] | [standalone]

#235032

> I have a blog, just a bunch of HTML5/CSS files, absolutely
> nothing advanced, and I'd like an RSS file which is
> generated from the HTML files (not the CSS, so even simpler
> actually) so I for example can submit it [to Gwene] and read
> it with Gnus

Speaking of Emacs (Emacs Gnus), in GNU ELPA there is webfeeder
[1] - actually I'd prefer a shell tool for this, but that's
just me - but after trying to get it to work for a long time,
I now give up. I don't know if that is also just me or if it
actually doesn't work?

The simple-enough example and boilerplate function looks like
this

  (webfeeder-build
  "atom.xml"
  "./public"
  "https://example.org/"
  '("post1.html" "post2.html" "post3.html")
  :title "My homepage"
  :description "A collection of articles in Atom")

so if anyone wants to try it should be simple. Tell me if you
have more success.

[1] https://gitlab.com/Ambrevar/emacs-webfeeder

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235034

Emanuel Berg wrote: 
> Andrei POPESCU wrote:
> 
> >> ... no one did it? :O
> >
> > In FLOSS this usually means nobody else needed it.
> 
> Impossible in this, basic case. The static generator guys who
> also did the RSS as mentioned already needed it, and did it,
> only not modular to fit this purpose (IIUC from reading here).

They totally did. As a library, not a standalone.

Because it turns out almost everybody needs consistency, and
that comes from dealing with the whole problem.

 
> > Why do you need it? Maybe we can suggest other means to
> > achieve your (true) goal.
> 
> True goal!
> 
> I have a blog [1], just a bunch of HTML5/CSS files, absolutely
> nothing advanced, and I'd like an RSS file [2] which is
> generated from the HTML files (not the CSS, so even simpler
> actually) so I for example can submit it here [2] and read it
> with Gnus :)
> 
> So one needs a parser to parse the HTML, dispose of
> unnecessary stuff, walk the tree (ha) and output it as
> an RSS file.

That's what all those static site generators do.

As a bonus, they usually offer templating (so the structure of
pages looks similar to each other) and shared CSS (so the
visuals are decoupled from the structure, and can be changed
without going in to every page to repeat tweaks.)

It sounds like you've written about a quarter of a static site
generator already. 

You could continue down that path, or just install Pelican and
be happy in about a day.

Don't become that person who gets angry at wheels because wheels
need axles and bearings when all you ever needed was a couple of
good round logs. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#235036

Dan Ritter wrote:

>>>> ... no one did it? :O
>>>
>>> In FLOSS this usually means nobody else needed it.
>> 
>> Impossible in this, basic case. The static generator guys who
>> also did the RSS as mentioned already needed it, and did it,
>> only not modular to fit this purpose (IIUC from reading here).
>
> They totally did. As a library, not a standalone.
>
> Because it turns out almost everybody needs consistency, and
> that comes from dealing with the whole problem.

Yes, but ever heard of independent tools working together?
E.g., this zsh

  hits=$(cut -d ' ' -f 2,8 $log | grep $p | sort | cut -d ' ' -f 1 | uniq -c | wc -l)

to make up a script or little program, e.g.

  https://dataswamp.org/~incal/blog/meta/piles

that produces the desired result:

  https://dataswamp.org/~incal/blog/hits.txt

Anyway that's what I would like here, if anyone else wants
something else somewhere else by all means don't make it
standalone, put it in a library... that we can't access (?) to
get a standalone either, maybe, it is too consistent with
everything else it is impossible to make out...

>>> Why do you need it? Maybe we can suggest other means to
>>> achieve your (true) goal.
>> 
>> True goal!
>> 
>> I have a blog [1], just a bunch of HTML5/CSS files,
>> absolutely nothing advanced, and I'd like an RSS file [2]
>> which is generated from the HTML files (not the CSS, so
>> even simpler actually) so I for example can submit it here
>> [2] and read it with Gnus :)
>> 
>> So one needs a parser to parse the HTML, dispose of
>> unnecessary stuff, walk the tree (ha) and output it as an
>> RSS file.
>
> That's what all those static site generators do.
>
> As a bonus, they usually offer templating (so the structure
> of pages looks similar to each other) and shared CSS (so the
> visuals are decoupled from the structure, and can be changed
> without going in to every page to repeat tweaks.)

I don't have to do that, as you see pages look similar and
there is just one CSS file:

  https://dataswamp.org/~incal/blog/index.html
  https://dataswamp.org/~incal/blog/global.css
  
> It sounds like you've written about a quarter of a static site
> generator already. 

Heh, no, what do you mean?

> You could continue down that path, or just install Pelican
> and be happy in about a day.

I would if it would do what I want namely get an RSS file and
only that. (Maybe it can even do that, I don't know.)

> Don't become that person who gets angry at wheels because
> wheels need axles and bearings when all you ever needed was
> a couple of good round logs.

Who is angry, I'm not angry and especially not at wheels:

  https://dataswamp.org/~incal/work-photos/stand.jpg
  https://dataswamp.org/~incal/#bike

But no one has or have heard of a CLI parser or shell tool...?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235044

Emanuel Berg wrote: 
> > It sounds like you've written about a quarter of a static site
> > generator already. 
> 
> Heh, no, what do you mean?
> 
> > You could continue down that path, or just install Pelican
> > and be happy in about a day.
> 
> I would if it would do what I want namely get an RSS file and
> only that. (Maybe it can even do that, I don't know.)

If only you read the documentation, you would know.

> But no one has or have heard of a CLI parser or shell tool...?

That is what a static site generator is.

It's a command-line tool that takes a directory full of content
files, a set of templates, a CSS file or 3, and spits out a
web site ready to be served by your favorite web server,
including the thing you asked for: an RSS or ATOM feed.

-dsr-

[toc] | [prev] | [next] | [standalone]

#235046

[Multipart message — attachments visible in raw view] — view raw

On 2021-05-09 at 15:36, Dan Ritter wrote:

> Emanuel Berg wrote:

>>> It sounds like you've written about a quarter of a static site 
>>> generator already.
>> 
>> Heh, no, what do you mean?
>> 
>>> You could continue down that path, or just install Pelican and be
>>> happy in about a day.
>> 
>> I would if it would do what I want namely get an RSS file and only
>> that. (Maybe it can even do that, I don't know.)
> 
> If only you read the documentation, you would know.
> 
>> But no one has or have heard of a CLI parser or shell tool...?
> 
> That is what a static site generator is.
> 
> It's a command-line tool that takes a directory full of content 
> files, a set of templates, a CSS file or 3, and spits out a web site
> ready to be served by your favorite web server, including the thing
> you asked for: an RSS or ATOM feed.

One possible difference is that the ones I've looked at (admittedly
nowhere near all of them) seem to expect the input to be in some other
format, to be translated into HTML etc., rather than letting you write
the HTML etc. directly and doing [whatever other things] with the
result. For example, the package description for pelican (which you
suggested earlier) says that it requires its input to be in Markdown or
rST.

In a case where you've already written the HTML et cetera and want to
continue to do so, these generators don't seem to be applicable to the
input form which you have available and want to continue to use.


For myself, if I were to write a static Website, I would probably do it
by literally writing the raw HTML (and probably not even using CSS, as
it goes against the "don't define how the output should look" principle
which I understand to have been part of HTML as it was originally
designed); the HTML, et cetera, output by any such generator would
probably not be in line with my preferences.

Then again, I'm not sure a static site of that type would really be
suitable for having an RSS-type feed of, since by definition it would be
static and not receiving updates such as might go into such a feed.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#235047

[Multipart message — attachments visible in raw view] — view raw

On Sun, 09 May 2021 17:38:06 -0400
The Wanderer <wanderer@fastmail.fm> wrote:

> One possible difference is that the ones I've looked at (admittedly
> nowhere near all of them) seem to expect the input to be in some other
> format, to be translated into HTML etc., rather than letting you write
> the HTML etc. directly and doing [whatever other things] with the
> result. For example, the package description for pelican (which you
> suggested earlier) says that it requires its input to be in Markdown
> or rST.

Right. However, as I found out asking elsewhere, you can include HTML
in Markdown. For example, Markdown doesn't by itself provide targets
for links. So in a glossary, I do this:

* <a id="eprom"></a>EPROM: Erasable Programmable Read Only Memory,

Now I can make a link to that target:

... and burn to ROM (or, more likely, [EPROM](#eprom)).

Feel free to experiment with it. I suspect you might have to remove the
<body> tags and everything outside them, and then have your static site
generator provide those. That might end up being an advantage.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#235051

Charles Curley wrote:

> Right. However, as I found out asking elsewhere, you can
> include HTML in Markdown.

Hehehe, let's see, first write HTML, then include it in
Markdown, then have the static site generator generate
HTML... brilliant :)

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235055

[Multipart message — attachments visible in raw view] — view raw

On Lu, 10 mai 21, 01:44:32, Emanuel Berg wrote:
> Charles Curley wrote:
> 
> > Right. However, as I found out asking elsewhere, you can
> > include HTML in Markdown.
> 
> Hehehe, let's see, first write HTML, then include it in
> Markdown, then have the static site generator generate
> HTML... brilliant :)

Surely there must be some site generator with RSS support that takes 
"plain" HTML as input.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#235059

Andrei POPESCU wrote:

>> let's see, first write HTML, then include it in Markdown,
>> then have the static site generator generate HTML
>
> Surely there must be some site generator with RSS support
> that takes "plain" HTML as input.

I don't know, if so one would like to know what tool they use
to do that?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235123

On Mon, May 10, 2021 at 03:03:33PM +0200, Emanuel Berg wrote:
>Andrei POPESCU wrote:
>
>>> let's see, first write HTML, then include it in Markdown,
>>> then have the static site generator generate HTML
>>
>> Surely there must be some site generator with RSS support
>> that takes "plain" HTML as input.
>
>I don't know, if so one would like to know what tool they use
>to do that?

IkiWiki can consume HTML. Although a default configuration of IkiWiki
would expect the input items to be HTML snippets - so, not full
documents containing HTML,HEAD,BODY tags, but subsets of the BODY
content. However it can be configured, with some work, to do pretty
much anything.

-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#235049

The Wanderer wrote:

> One possible difference is that the ones I've looked at
> (admittedly nowhere near all of them) seem to expect the
> input to be in some other format, to be translated into HTML
> etc., rather than letting you write the HTML etc.
> directly and doing [whatever other things] with the result.
> For example, the package description for pelican (which you
> suggested earlier) says that it requires its input to be in
> Markdown or rST.
>
> In a case where you've already written the HTML et cetera
> and want to continue to do so, these generators don't seem
> to be applicable to the input form which you have available
> and want to continue to use.

Yes, that's exactly it, thank you!

But, I was thinking, aren't there tools to do the generator or
builder?

How does that work, you write a syntax grammar and feed it
to yacc?

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235057

The Wanderer wrote: 
> On 2021-05-09 at 15:36, Dan Ritter wrote:
> 
> > That is what a static site generator is.
> > 
> > It's a command-line tool that takes a directory full of content 
> > files, a set of templates, a CSS file or 3, and spits out a web site
> > ready to be served by your favorite web server, including the thing
> > you asked for: an RSS or ATOM feed.
> 
> One possible difference is that the ones I've looked at (admittedly
> nowhere near all of them) seem to expect the input to be in some other
> format, to be translated into HTML etc., rather than letting you write
> the HTML etc. directly and doing [whatever other things] with the
> result. For example, the package description for pelican (which you
> suggested earlier) says that it requires its input to be in Markdown or
> rST.


"Pelican can also process HTML files ending in .html and .htm."
-- https://docs.getpelican.com/en/latest/content.html

> Then again, I'm not sure a static site of that type would really be
> suitable for having an RSS-type feed of, since by definition it would be
> static and not receiving updates such as might go into such a feed.

The static refers to this: the pile of data is processed when
you assemble it, not when a viewer asks for it.

When you make a change -- editing a page, adding a page,
deleting one, changing some feature -- you commit the change and
the generator does its work again. This tyically takes between
0.1 and 10 seconds. Then everything is static again.

-dsr-

[toc] | [prev] | [next] | [standalone]

#235061

Dan Ritter wrote:

> The static refers to this: the pile of data is processed
> when you assemble it, not when a viewer asks for it

Well, of course not...

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235054

[Multipart message — attachments visible in raw view] — view raw

On Du, 09 mai 21, 20:15:38, Emanuel Berg wrote:
> Dan Ritter wrote:
> 
> >>>> ... no one did it? :O
> >>>
> >>> In FLOSS this usually means nobody else needed it.
> >> 
> >> Impossible in this, basic case. The static generator guys who
> >> also did the RSS as mentioned already needed it, and did it,
> >> only not modular to fit this purpose (IIUC from reading here).
> >
> > They totally did. As a library, not a standalone.
> >
> > Because it turns out almost everybody needs consistency, and
> > that comes from dealing with the whole problem.
> 
> Yes, but ever heard of independent tools working together?

Except that an HTML to RSS converter is is basically useless by itself.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#235060

Andrei POPESCU wrote:

> Except that an HTML to RSS converter is is basically useless
> by itself.

Well, it is (would be) useful in my setting which thanks
heaven includes other tools and programs :)

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#235037

Dan Ritter wrote:

>> I don't know why, but it seems too involved anyway, there
>> isn't a webpile2rss tool like this or something:
>> 
>>   $ webpile2rss *.html > rss.xml # sweet
>
> There isn't one packaged in Debian, but there are libraries
> packaged which would allow you to build one.

... no one did it? :O

> You might be happy with a static site generator, which takes
> a directory full of documents and arranges them into
> a website, usually including an RSS or ATOM feed.

Well, I already have that, well, whatever it means, I want
only the RSS...

-- 
underground experts united
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web