operations on path lists

operations on path lists

[Samuel Wales]

suppose i do

  find . -iname '*foo*' -type d | sort

and suppose that i want to copy these dirs to another dir, or so.  the
components and paths can be long.

it gets confusing, trying to interpret these paths.  what is
underneath what in the fs tree?

i'd like to do at least one of the following operations on this list.
i don't know which would be more clear in all cases.


1.  shortcut all subsequent paths

if a path is like ./.../...foo.../.../...foo..., then eliminate that line.
i.e. eliminate paths that have common prefix paths on any previous line.

2.  highlight adjacent subsequent paths' common components

if i have paths like

./hi/foo
./hi/there/foo
./whatever/whatever/foo

then i want line 2 to have ./hi/ highlighted.  i might also like this
one for, not paths, but lines, to show intra-component differences.
but in that case, it might be the difference i want highlghted, and it
need not be a prefix or a suffix.


is there anything like any of these in emacs?  i don't know of a cli
solution either.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: operations on path lists

[Jean Louis]

* Samuel Wales <samologist@gmail.com> [2023-02-04 08:34]:
> suppose i do
> 
>   find . -iname '*foo*' -type d | sort

It is possible to use Emacs Lisp:

(sort 
 (delq nil 
       (mapcar
	(lambda (file)
	  (cond ((file-directory-p file) (expand-file-name file))
		(t nil)))
	(directory-files-recursively 
	 (expand-file-name "~/Documents/") ".*Q.*" t)))
       #'string<)

It would be better to have `directory-directories-recursively' function.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

> (cond ((file-directory-p file) (expand-file-name file))
>       (t nil))

(when (file-directory-p file)
  (expand-file-name file) )

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

RE: [External] : Re: operations on path lists

[Drew Adams]

> > (cond ((file-directory-p file) (expand-file-name file))
> >       (t nil))
> 
> (when (file-directory-p file) (expand-file-name file) )

(and (file-directory-p file)  (expand-file-name file))

Use `when' when the return value isn't important.
Helps human readers.

Re: [External] : Re: operations on path lists

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-02-04 20:23]:
> > > (cond ((file-directory-p file) (expand-file-name file))
> > >       (t nil))
> > 
> > (when (file-directory-p file) (expand-file-name file) )
> 
> (and (file-directory-p file)  (expand-file-name file))
> 
> Use `when' when the return value isn't important.
> Helps human readers.

I understand the idea, and I found `cond' serves that purpose better.

So I follow the same purpose in the essence.

In that particular example, the return value would be rather hidden
and implied from `when'.

For me that is not same as when the value is visible, such as `nil'.

So those are differences in view points on what is helpful to human
reader or not.

If reader is familiar with `when' and not with `cond' it will be
easier, but if readier is familiar with `cond' maybe that is easier.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

>>>> (cond ((file-directory-p file) (expand-file-name file))
>>>>       (t nil))
>>> 
>>> (when (file-directory-p file) (expand-file-name file) )
>> 
>> (and (file-directory-p file)  (expand-file-name file))
>> 
>> Use `when' when the return value isn't important.
>> Helps human readers.
>
> I understand the idea, and I found `cond' serves that
> purpose better.
>
> So I follow the same purpose in the essence.
>
> In that particular example, the return value would be rather
> hidden and implied from `when'.

?

> For me that is not same as when the value is visible, such
> as `nil'.
>
> So those are differences in view points on what is helpful
> to human reader or not.
>
> If reader is familiar with `when' and not with `cond' it
> will be easier, but if readier is familiar with `cond' maybe
> that is easier.

The reader ... you, the writer, should write as good code as
possible, that will benefit everyone the same way.

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

Re: [External] : Re: operations on path lists

[Jean Louis]

> > If reader is familiar with `when' and not with `cond' it
> > will be easier, but if readier is familiar with `cond' maybe
> > that is easier.
> 
> The reader ... you, the writer, should write as good code as
> possible, that will benefit everyone the same way.

Yes, and that is matter of opinions.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

>>> If reader is familiar with `when' and not with `cond' it
>>> will be easier, but if readier is familiar with `cond'
>>> maybe that is easier.
>> 
>> The reader ... you, the writer, should write as good code
>> as possible, that will benefit everyone the same way.
>
> Yes, and that is matter of opinions.

Not in this case.

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

Re: [External] : Re: operations on path lists

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-05 16:16]:
> The reader ... you, the writer, should write as good code as
> possible, that will benefit everyone the same way.

OK sure, but where is the definition of "as good code as possible"?

It is opinionated.

Every person, so I expect, strives to write "as good code as
possible".

Let us look at `when' little:

- you place `when' when you need `nil' as last resort

- what if you change your mind in future and wish to modify function
  to return "" as last resort? You will need to introduce `if`
  function, you have to restructure it. You have to remove `when' and
  replace with something else.

- without parenthesis highlighting sometimes it becomes very difficult
  to understand what did `if' author intended to say? 

- multiple `if' statements one ofter other do not look nice and
  readable, and I have to use

- if you use `cond', you remain with `cond', but only change nil to ""

Some people write long functions, if, then, when, it is not nicely
indented, restructuring is difficult, what did author want to say?
Hard to think of it.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: operations on path lists

[Drew Adams]

> Let us look at `when' little:
> 
> - you place `when' when you need `nil' as last resort

I don't.  I do just the opposite.  I use `when'
and `unless' only when the code doesn't use/depend
on the return value.  (I'm guessing that's what
you meant by needing nil as a last resort, though
they always return nil.)

Before Elisp borrowed `when' and `unless' from
other Lisps (e.g. Common Lisp), the idiom,
especially for a single condition, was to use `or'
in (or condition do-something) instead of `unless',
and likewise for `and' and `when'.  That that,
usually at top level in a function body.  I still
have some of those `or' sexps, as does standard
Emacs code.

> - what if you change your mind in future and wish to modify function
>   to return "" as last resort?

I don't use `when' for its return value (which,
again, is always nil).  I might use `if' or `and'
(or `case' or `cond'...).

>   you have to restructure it.

Yes, I mentioned this in my reply to EB yesterday.
That's the advantage of doing what you prefer to
do, e.g., use `cond'.  At the cost of losing any
indication of the meaning/intention of any given
`cond' clause and the return value.

`cond' is a very versatile control structure that,
consequently, gives you little means to express
intention, other than with comments.  One `cond'
clause looks like any other - could do or mean,
and return, anything at all.

> - without parenthesis highlighting sometimes it becomes very difficult
>   to understand what did `if' author intended to say?

I don't grok that.  But then, I don't use `if'
unless there are both a then and an else part.
I take the time to rewrite, yes, as needed,
to communicate to myself (as reader) just what
the code means to do.

> - multiple `if' statements one ofter other do not look nice and
>   readable,

That's not very common IMO.  Maybe a couple
levels sometimes.

> Some people write long functions, if, then, when, it is not nicely
> indented, restructuring is difficult, what did author want to say?
> Hard to think of it.

Probably depends on what you're used to.  But
if each of `if', `when', `unless', `and', and
`or' is used in a way that says what's intended
then it's pretty easy to understand.  There's
no guessing about whether the return value of
a given `if' is used etc.  (For me, it always
is, or I wouldn't use `if'.)

RE: [External] : Re: operations on path lists

[Drew Adams]

> But if each of `if', `when', `unless', `and', and
> `or' is used in a way that says what's intended
> then it's pretty easy to understand.  There's
> no guessing about whether the return value of
> a given `if' is used etc.  (For me, it always
> is, or I wouldn't use `if'.)

I misspoke there.  I use `if' in contexts where
the return value matters and in contexts where
it doesn't matter.

Re: [External] : Re: operations on path lists

[Jean Louis]

> > Let us look at `when' little:
> > 
> > - you place `when' when you need `nil' as last resort

The above I was thinking 💭, maybe by mistake, that I am answering to
Swedish friend.

> I don't.  I do just the opposite.  I use `when' and `unless' only
> when the code doesn't use/depend on the return value.  (I'm guessing
> that's what you meant by needing nil as a last resort, though they
> always return nil.)

Thanks, I got your thinking, I like when I enter in your mind with
such details, thanks much. What interesting stuff goes on over
thousands of miles of distance.

Yes, I know those return nil. You got my idea, thanks.

> Before Elisp borrowed `when' and `unless' from other Lisps
> (e.g. Common Lisp), the idiom, especially for a single condition,
> was to use `or' in (or condition do-something) instead of `unless',
> and likewise for `and' and `when'.  That that, usually at top level
> in a function body.  I still have some of those `or' sexps, as does
> standard Emacs code.

Okay, I get the history, thanks.

> > - without parenthesis highlighting sometimes it becomes very difficult
> >   to understand what did `if' author intended to say?
> 
> I don't grok that.

With `cond' I can see, usually, what is meant with the condition, as
it is at least to me better structured than `if', as complexity of
code requires me to count parenthesis or be very careful to understand
which expression belong to which part of `if' or some `if` that
follows up. With parenthesis highlighting that is helped better.

> But then, I don't use `if' unless there are both a then and an else
> part.  I take the time to rewrite, yes, as needed, to communicate to
> myself (as reader) just what the code means to do.

Yes, it is good to communicate to oneself over periods of time, I
forgot already what I was doing back in time, sometimes I study my
program to find out what did I mean with it.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: operations on path lists

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-04 17:55]:
> Jean Louis wrote:
> 
> > (cond ((file-directory-p file) (expand-file-name file))
> >       (t nil))
> 
> (when (file-directory-p file)
>   (expand-file-name file) )

I am aware of it, I prefer using `cond' as I get more clarity. 

You may get more clarity with `when'.

Btw. it reminds me that I also have `rcd-unless':

(defmacro rcd-unless (condition &optional message &rest body)
  (declare (indent 2))
  `(cond (,condition
	  ,@body)
	 (t (rcd-message ,message))))

So I use it this way:

(rcd-unless nil
    "Cannot execute"
  (message "OK I execute"))

I am not sure if I will keep it, but I like it. `rcd-message' you can replace with `message' to understand it.

As often I have situation where in the `unless' condition I want to tell to user "why" it does not work. So message is displayed in mini buffer.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

>>> (cond ((file-directory-p file) (expand-file-name file))
>>>       (t nil))
>> 
>> (when (file-directory-p file)
>>   (expand-file-name file) )
>
> I am aware of it, I prefer using `cond' as I get
> more clarity.

The (t nil) part is of no use, even if you stick to `cond'.

  "If no clause succeeds, cond returns nil."

And: one COND, one branch or BODY - in idiomatic Lisp, that's
`when'.

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

Re: operations on path lists

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-05 16:15]:
> Jean Louis wrote:
> 
> >>> (cond ((file-directory-p file) (expand-file-name file))
> >>>       (t nil))
> >> 
> >> (when (file-directory-p file)
> >>   (expand-file-name file) )
> >
> > I am aware of it, I prefer using `cond' as I get
> > more clarity.
> 
> The (t nil) part is of no use, even if you stick to `cond'.
> 
>   "If no clause succeeds, cond returns nil."
> 
> And: one COND, one branch or BODY - in idiomatic Lisp, that's
> `when'.

I use it to see the `nil'. 

To help person how you think is better, then write it in your way for
that person. 

`cond' in my world has special place, it is not really replacement for
`if' or other conditionals. It is used in period of programming as it
helps with thinking during the function ripening.

In general I will first want to define what the function should return
without other conditions. The ripening process begins.

(defun my-function (arg)
  (cond (t (user-error "Verify me"))))

Then I start adding conditions:

(defun my-function (arg)
  (cond ((zerop arg) (message "Worked"))
	(t nil)))

And more to it:

(defun my-function (arg)
  (cond ((stringp arg) (message "I got `%s'" arg))
	((zerop arg) (message "Worked"))
	(t nil)))

and then I add more:

(defun my-function (arg)
  (cond ((numberp arg) (message "I got number `%s'" arg))
	((stringp arg) (message "I got string `%s'" arg))
	((zerop arg) (message "Worked"))
	(t nil)))

I hope you can see how conditions are developed during time. In the
process of ripening it is good to see `nil' visually in the last
condition from beginning. 

The return can be `nil' but also something else.

Once function is "stable", then I may remove what is not any more
necessary for some readers.

Got that one?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

> To help person how you think is better, then write it in
> your way for that person.

Nope, we write code for computers, not for people.

Only comments are written for people - and they should only
denote stuff that sticks out as weird, thus needs to
be explained.

So you should put a comment to this one, since it doesn't make
any sense:

  (t nil) ; I put it that way to make it more clear to you,
         ;; the reader

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

RE: [External] : Re: operations on path lists

[Drew Adams]

> > To help person how you think is better, then write it in
> > your way for that person.
> 
> Nope, we write code for computers, not for people.

I write if for myself, by way of the computer.

> Only comments are written for people - and they should only
> denote stuff that sticks out as weird, thus needs to
> be explained.

I disagree that only comments are written for people.
Code written for easy understanding by people - other
things being equal - is far more useful.  (And more
beautiful/elegant.)

Depending on the language, elegant code communicates
better than inelegant code plus comments to lipstick
the pig.  In general, the more elegant the language,
the less human-language code (aka comments) is needed
to communicate among us.

RE: [External] : Re: operations on path lists

[Drew Adams]

> > > I am aware of it, I prefer using `cond' as I get
> > > more clarity.
> >
> > The (t nil) part is of no use, even if you stick to `cond'.
> >
> >   "If no clause succeeds, cond returns nil."
> >
> > one COND, one branch or BODY - in idiomatic
> > Lisp, that's `when'.
> 
> I use it to see the `nil'.
> `cond' in my world has special place, it is not really replacement for
> `if' or other conditionals. It is used in period of programming as it
> helps with thinking during the function ripening.
> 
> In general I will first want to define what the function should return
> without other conditions. The ripening process begins.
>
> I hope you can see how conditions are developed during time. In the
> process of ripening it is good to see `nil' visually in the last
> condition from beginning.

Indeed, cond is easier for making changes
to the behavior.  Not just initially - the
process you describe, but also over longer
periods of time and larger code changes -
evolution.

> Once function is "stable", then I may remove
> what is not any more necessary for some readers.

Yes again.  That's the point that I and
others have been making: communication
to human readers through the code itself.

I personally prefer to keep the code in
(what to me is) the most human-readable
form throughout.  But yes, that can mean
more code shuffling/restructuring as
things evolve.  Sometimes a lot more.

Most of the time I'm the only human who
reads my code.  But I today am not I
tomorrow.  What I understand when writing
some code, especially if complex, can be
different from what I understand when
reading it later, especially much later.

Sometimes I feel like old Krapp in
"Krapp's Last Tape", unable to recognize
his self that he recorded decades earlier.

https://en.wikipedia.org/wiki/Krapp%27s_Last_Tape

Re: operations on path lists

[Samuel Wales]

thanks.  i was aware that emacs lisp can do that find.  i was trying
to be clear about the origin of the path list, so as to help motivate
the example of a set of lines that, in the case i was omst interested
in, were fs paths.

also, i put in the sort, but could hae left it out for better
generality.  but the find could be much more complex and part of
something that naturally occurs while using the shell in shell mode,
and further processing like deleting lines can be done.  the point i
was trying to make is that i have a set of lines.  and the sub-case of
lines that are paths is what i was most interested in.

and the problem is one of distinguishing the lines so that there is
more clarity for the user.  and possibly shortcutting.

in other words, i was not asking about find, but about the path lists.
:]  but thank you for the find code.  :]


On 2/4/23, Jean Louis <bugs@gnu.support> wrote:
> * Emanuel Berg <incal@dataswamp.org> [2023-02-04 17:55]:
>> Jean Louis wrote:
>>
>> > (cond ((file-directory-p file) (expand-file-name file))
>> >       (t nil))
>>
>> (when (file-directory-p file)
>>   (expand-file-name file) )
>
> I am aware of it, I prefer using `cond' as I get more clarity.
>
> You may get more clarity with `when'.
>
> Btw. it reminds me that I also have `rcd-unless':
>
> (defmacro rcd-unless (condition &optional message &rest body)
>   (declare (indent 2))
>   `(cond (,condition
> 	  ,@body)
> 	 (t (rcd-message ,message))))
>
> So I use it this way:
>
> (rcd-unless nil
>     "Cannot execute"
>   (message "OK I execute"))
>
> I am not sure if I will keep it, but I like it. `rcd-message' you can
> replace with `message' to understand it.
>
> As often I have situation where in the `unless' condition I want to tell to
> user "why" it does not work. So message is displayed in mini buffer.
>
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: operations on path lists

[Samuel Wales]

i should have left out the find altogether.  i eill try to be more
clear next time.  although i really tried.  :]

On 2/4/23, Samuel Wales <samologist@gmail.com> wrote:
> thanks.  i was aware that emacs lisp can do that find.  i was trying
> to be clear about the origin of the path list, so as to help motivate
> the example of a set of lines that, in the case i was omst interested
> in, were fs paths.
>
> also, i put in the sort, but could hae left it out for better
> generality.  but the find could be much more complex and part of
> something that naturally occurs while using the shell in shell mode,
> and further processing like deleting lines can be done.  the point i
> was trying to make is that i have a set of lines.  and the sub-case of
> lines that are paths is what i was most interested in.
>
> and the problem is one of distinguishing the lines so that there is
> more clarity for the user.  and possibly shortcutting.
>
> in other words, i was not asking about find, but about the path lists.
> :]  but thank you for the find code.  :]
>
>
> On 2/4/23, Jean Louis <bugs@gnu.support> wrote:
>> * Emanuel Berg <incal@dataswamp.org> [2023-02-04 17:55]:
>>> Jean Louis wrote:
>>>
>>> > (cond ((file-directory-p file) (expand-file-name file))
>>> >       (t nil))
>>>
>>> (when (file-directory-p file)
>>>   (expand-file-name file) )
>>
>> I am aware of it, I prefer using `cond' as I get more clarity.
>>
>> You may get more clarity with `when'.
>>
>> Btw. it reminds me that I also have `rcd-unless':
>>
>> (defmacro rcd-unless (condition &optional message &rest body)
>>   (declare (indent 2))
>>   `(cond (,condition
>> 	  ,@body)
>> 	 (t (rcd-message ,message))))
>>
>> So I use it this way:
>>
>> (rcd-unless nil
>>     "Cannot execute"
>>   (message "OK I execute"))
>>
>> I am not sure if I will keep it, but I like it. `rcd-message' you can
>> replace with `message' to understand it.
>>
>> As often I have situation where in the `unless' condition I want to tell
>> to
>> user "why" it does not work. So message is displayed in mini buffer.
>>
>>
>> --
>> Jean
>>
>> Take action in Free Software Foundation campaigns:
>> https://www.fsf.org/campaigns
>>
>> In support of Richard M. Stallman
>> https://stallmansupport.org/
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

>> suppose i do
>> 
>>   find . -iname '*foo*' -type d | sort
>
> It is possible to use Emacs Lisp

Jean, can't you make some Elisp semi-AI that will parse and
translate from shell commands to Elisp and back :)

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

Re: operations on path lists

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-05 16:15]:
> Jean Louis wrote:
> 
> >> suppose i do
> >> 
> >>   find . -iname '*foo*' -type d | sort
> >
> > It is possible to use Emacs Lisp
> 
> Jean, can't you make some Elisp semi-AI that will parse and
> translate from shell commands to Elisp and back :)

I was thinking that Emacs Lisp is implementation language of shell. 🤔

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: operations on path lists

[Emanuel Berg]

Jean Louis wrote:

>>>> suppose i do
>>>> 
>>>>   find . -iname '*foo*' -type d | sort
>>>
>>> It is possible to use Emacs Lisp
>> 
>> Jean, can't you make some Elisp semi-AI that will parse and
>> translate from shell commands to Elisp and back :)
>
> I was thinking that Emacs Lisp is implementation language of
> shell. 🤔

And shell the extension language of the sea ...

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

Re: operations on path lists

[James Thomas]

Samuel Wales wrote:

> 1.  shortcut all subsequent paths
>
> if a path is like ./.../...foo.../.../...foo..., then eliminate that line.
> i.e. eliminate paths that have common prefix paths on any previous line.

(With point at the beginning, do) M-x replace-regexp RET, then paste the
following expression (without quotes - note the newline at the
beginning), then RET twice.

"
.*\(/[^/
]*foo[^/
]\).*\1.*$"

> 2.  highlight adjacent subsequent paths' common components
>
> if i have paths like
>
> ./hi/foo
> ./hi/there/foo
> ./whatever/whatever/foo
>
> then i want line 2 to have ./hi/ highlighted.  i might also like this
> one for, not paths, but lines, to show intra-component differences.
> but in that case, it might be the difference i want highlghted, and it
> need not be a prefix or a suffix.

This can also be done with a similar regexp. I suggest you get familiar
with "Syntax of Regexps" in the Elisp manual. You will also need this:

https://emacs.stackexchange.com/questions/37272/highlight-different-regexp-groups-with-different-colors

> and suppose that i want to copy these dirs to another dir, or so.  the
> components and paths can be long.

Additionally, you can set the resulting buffer in dired-virtual-mode
(from the dired-x package) and then run:

M-: (setq-local directory-listing-before-filename-regexp " +") RET

...to use it as a normal dired buffer (for copying, deleting etc).

--

Re: operations on path lists

[Ruijie Yu via Users list for the GNU Emacs text editor]

Samuel Wales <samologist@gmail.com> writes:

> [...]
> is there anything like any of these in emacs?  i don't know of a cli
> solution either.

I believe there is.  See https://gitlab.com/OldManProgrammer/unix-tree
and its manpage.  Especially, take a look at the "--fromfile" option, as
it allows "tree" to take listings (similar to your example) from stdin
instead of from the filesystem.

Best,


RY