On Wed, Jun 6, 2012 at 4:35 PM, Lars Ellenberg <[email protected]>wrote:
> On Wed, Jun 06, 2012 at 02:06:19PM +0300, Borislav Borisov wrote:
> > > Ok. So we forgot about exportfs "*:/path",
> > > which is shown as /path <world>.
> > >
> > > I'd like to have it anchored.
> > > oes this still work for you?
> > >
> > > + sed -e '$! N; s/\n[[:space:]]\+/ /; t;
> > > s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/g; s/ <world>$/ */g;
> P;D;'
> >
> >
> > To some extent it does... it will catch the ones that end with <world>,
> but
> > the problem is the search and replaces used are appending a newline.
> Also,
> > I initially missed a replace after the first search and replace.
> Eventually
> > I ended up with something close to what you want:
> > sed -e '$! N; s/\n[[:space:]]\+/ /; s/ <world>$/ */g; t;
> > s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/g; s/ <world>\(\n\|$\)/
> > *\1/g; P;D;'
> >
> > That one, however, is bugging me a lot.
>
> It is not even strictly correct, I think.
>
You need to change the order of the first too substitutions for the "t;"
> to be correct. See below.
>
> It actually was acting correct, but you do have a point, the other way
around makes more sense.
> > So I came up with another solution,
> > which of course isn't anchored either, but is more readable:
> > sed -n '1h; 1!H; ${g; s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/
> \1\2/g; s/ <world>/ */g; p}'
>
> I don't like that this is first reading all of it,
> then do a replace over all of it.
> It also breaks if you have white space in path names (which is probably
> a very bad practise, in case it is even legal ;-)
>
>
> > I do not consider myself a sed guru, maybe someone who is can figure a
> > better approach.
>
> I think this one is correct, please see if you can break it.
>
> sed -e '$! N;s/\n[[:space:]]\+<world>/ */; s/\n[[:space:]]\+/ /; t;
> s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/; s/ <world>\(\n\|$\)/
> *\1/; P;D;'
>
>
If the last line matches the first search/replace everything works as
expected, unfortunately if it ends with a line that has the path and client
spec it breaks on the last line, naturally. Which could explain why you
had s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/g originally.
> Note that I dropped the /g from the latter substitutions.
>
> FMTYEWTK:
> $! N; # append next line, unless end of file
> s/\n[[:space:]]\+<world>/ */;
> # join continuation lines and replace <world>, if present.
> s/\n[[:space:]]\+/ /;
> # join continuation lines. can not succeed if previous line
> succeeded.
> t; # if one of the previous two "join lines" succeeded,
> # print and start new cycle.
>
> # else:
> # we have one single line record,
> # and a potentially partial record as second line
>
> s/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/;
> # squeeze spaces between path and client spec
> # If we put a /g on there, it may also squeeze spaces
> # within the path spec of a trailing partial record.
>
I tried adding /g to both this one and the one below and ran it vs
ridiculously long path and a path with space in the name (which would
prompt a warning saying that action is not supported, but added the
directory to exportfs anyway) and didn't cause any unexpected behavior.
Just to make sure I ran it agains't a directory with several spaces in it.
# Which is why I left it off now.
> # Not sure why I put it in there in the first place.
> s/ <world>\(\n\|$\)/ *\1/;
> # if the client spec is <world>, substitute by *
> P; # print up to the first newline
> D; # delete up to the first newline and start new cycle
>
>
> If we can be sure that exportfs output will always be \n terminated,
> we could leave off the \(\n\|$\) ... \... parts.
>
> Would it be easier to the eye if we break it up into single statements?
>
> sed -e '$! N;' \
> -e 's/\n[[:space:]]\+<world>/ */;' \
> -e 's/\n[[:space:]]\+/ /;' \
> -e 't;' \
> -e 's/[[:space:]]\+\([^[:space:]]\+\)\(\n\|$\)/ \1\2/;' \
> -e 's/ <world>\(\n\|$\)/ *\1/;' \
> -e 'P;D;'
>
> I do not think that it makes a huge difference, but sure is easy on the
eyes.
> Again, please, everybody:
> try to break this with any output exportfs may produce.
>
> If only ... I mean, well, it is 2012, right?
> ah well, never mind :-/
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
