> Could somebody please review my patch - if there are no objections (but
> I am sure there are some more details that can be improved), I will
> write a PR.
I have filed a PR in order to preserve this patch. It can be found here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=55539
Regards,
Simon
> imho - expensive algorithm... i want to see anything more simple...
> like "gtok()" instead "es_strsep() + remove_escapes()"?
I have adopted my patch to use your neat gtok() function, but I came to
the conclusion that a two-pass algorithm is necessary:
The first pass detects whether a line fro
On Mon, Aug 04, 2003 at 02:33:31AM +0200, Simon Barner wrote:
> Hi Terry,
>
> > You need to add '\\' to the list of characters that can be escaped,
> > or you've just traded the inability to specify '\t' or ' ' for an
> > inability to speciy '\\'.
>
> Oh yes, I have overlook this special case. I
On Tue, 2003-08-05 at 11:05, Simon Barner wrote:
> Hi,
>
> > Check PR 37569: This bugged the hell out of me also, so I created a
> > patch to allow enclosing the device name in quotes. The PR was logged
> > over a year ago: I can't remember the details, but the source has been
> > sitting silently
Hi,
Check PR 37569: This bugged the hell out of me also, so I created a
patch to allow enclosing the device name in quotes. The PR was logged
over a year ago: I can't remember the details, but the source has been
sitting silently in my tree and working since then. Whatever way the
problem is resolv
Hi,
> Check PR 37569: This bugged the hell out of me also, so I created a
> patch to allow enclosing the device name in quotes. The PR was logged
> over a year ago: I can't remember the details, but the source has been
> sitting silently in my tree and working since then. Whatever way the
> proble
Hi Terry,
> You need to add '\\' to the list of characters that can be escaped,
> or you've just traded the inability to specify '\t' or ' ' for an
> inability to speciy '\\'.
Oh yes, I have overlook this special case. I revised my patch in order
to get this right.
Simon
--- fstab.c.orig
Simon Barner wrote:
> The attached patch will allow blanks and tabs for file systems and
> path names, as long as the are protected by a '\'.
>
> For the old fstab style, blanks and tabs are not allowed as delimiters
> (as it was in the old implementation).
You need to add '\\' to the delimited l
Hi,
> For all the 'good rules' of orthonogolity and consistency etc
> it is a good thing, however I still feel that at the level of
> the fstab where you are mounting entire file system trees,
> the simplest naming formats are probably the best.
> A philosophical point only, but it would keep t
Chris BeHanna wrote:
> What about
>
> test%201/mnt/test%201 ufs ro 0 0
>
> ?
> Ugly, yes, but that's how a lot of tools escape spaces.
"%" is almost infinitely more likely in a path than "\"; better
to use the "\" than the "%" mechanism. Also, the parser can
b LALR
On Thu, 31 Jul 2003, Chris BeHanna wrote:
> What about
>
> test%201/mnt/test%201 ufs ro 0 0
>
> ?
> Ugly, yes, but that's how a lot of tools escape spaces.
Just FYI, here is how Linux handles this (from fstab(5)):
The second field, (fs_file), describes the mount poi
At 10:16 PM -0400 7/31/03, Chris BeHanna wrote:
> Sorry, I should have written that I have performed tests:
Here is what I did:
test\ 1 /mnt/test\ 1ufs ro 0 0
'test 2''/mnt/test 2' ufs ro 0 0
> "test 3"
On Thu, 31 Jul 2003, Simon Barner wrote:
> > Just a thort, not having tried it ..
> >
> > does either of the 'standard' methods of including spaces actually work
> > in fstab ??
> >
> > I speak of quoting (either single or double) and backslashing the space
> >
> > "/mnt/space/silly long dirname/f
For all the 'good rules' of orthonogolity and consistency etc
it is a good thing, however I still feel that at the level of
the fstab where you are mounting entire file system trees,
the simplest naming formats are probably the best.
A philosophical point only, but it would keep the fstab format
Hi,
> This very discussion came up in -questions a few months ago (or maybe it was
> late last year). The conclusion was that unless someone rewrites the
> /etc/fstab parsing routines in libc to support quoted and/or escaped spaces,
> we'll never be able to mount filesystems that have spaces in t
No, none of these methods will work.
This very discussion came up in -questions a few months ago (or maybe it was
late last year). The conclusion was that unless someone rewrites the
/etc/fstab parsing routines in libc to support quoted and/or escaped spaces,
we'll never be able to mount filesyst
> Just a thort, not having tried it ..
>
> does either of the 'standard' methods of including spaces actually work
> in fstab ??
>
> I speak of quoting (either single or double) and backslashing the space
>
> "/mnt/space/silly long dirname/filename also with spaces"
>
> or
>
> /mnt/space/silly
Just a thort, not having tried it ..
does either of the 'standard' methods of including spaces actually work
in fstab ??
I speak of quoting (either single or double) and backslashing the space
"/mnt/space/silly long dirname/filename also with spaces"
or
/mnt/space/silly\ long\ dirname/filename
Do file system names and mount points with whitespaces violate the
specification of fstab? If so, the least thing I'd suggest is the document
this restriction.
Or should one extend 'getfsent' such that is able to cope with those
whitespaces? I am not sure whether this would have any further
implica
>From the man page
Each filesystem is described on a separate line; fields on each line are
separated by tabs or spaces.
Clearly, having a space in a filesystem or mount point will violate
this constraint, by causing the trailing part to become the next
field.
Given that this is such a fun
Hi -hackers,
discussing some modifications for the sysutils/linneighborhood port,
Heiner Eichmann and me came across the following problem:
getfsent(3) will fail, if the name of the file system or the mount point
contains whitespaces, be them escaped or not (file system names with
spaces occur qu
21 matches
Mail list logo
