edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] glob, wordexp
Date: Sun, 28 Dec 2014 19:35:50 +0000	[thread overview]
Message-ID: <20141228193550.GB16901@spoons.adamthompson.me.uk> (raw)
In-Reply-To: <20141128140919.eklhad@comcast.net>

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Sun, Dec 28, 2014 at 02:09:19PM -0500, Karl Dahlke wrote:
> Edbrowse has the feature that you can read or write files using shell variables
> and even wildcard expansion, if the result is one file.
> I use this feature all the time!
> 
> r ~/work/whatever/st*k.c
> w $backup/12-25-14.c
> 
> and things like that.

Wow, I knew about ~ expansion and env variables but didn't know about wildcards.

> Most of this is done by envFile() in stringfile.c,
> which is 200 lines of rather awkward code.
> I would like to replace most of this with a call to glob or wordexp.
> This leverages existing libraries, and is more portable,
> since someone else is reading through subdirectories etc.

Agreed.
> Are there any reasons I should or should not do this, or any thoughts on this?
> I know glob does too little, it doesn't expand shell variables,
> but wordexp may do too much,
> like all the fancy things bash does to a line.

Yeah, wordexp does massive amounts of things (including command substitution).
Looking through the man page, the only thing you can turn off is the command substitution.
This essentially means that any file names you give it *must* be in legal posix
shell syntax which may or may not be an issue.

I'd say you should go with wordexp (may as well leave in the command
substitution since that could be quite powerful)
as long as you make sure that the readline tab completion feature
yields file names escaped for use in the shell.

On a semi-related note, what're people's thoughts on enabling readline's history feature?
I personally find myself wanting this on an almost daily basis,
but didn't want to do it in case there's a good reason not to.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

      reply	other threads:[~2014-12-28 19:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-28 19:09 Karl Dahlke
2014-12-28 19:35 ` Adam Thompson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141228193550.GB16901@spoons.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).