Why xfs_<utils> not 'readline' w/line-edit & history enabled?

Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

Something I've long wished for and wondered why it wasn't
there -- was the ability to edit or re-edit a typed line,
or recall a previous line from history.

I'd really find it useful to even have the ability for it to
save previous command sessions / tool.

Given the usefulness of such, I was wondering why it had
never been done?   Just it never rose to the top of some
task list?  Or was there some desire to keep the tools
less friendly and thus make them more difficult to use for
casual use (i.e. it might have been a conscious design
decision at some point).  Is that reasoning still a strong
enough factor to keep things like that out of the mainline
code?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Kinzel, David]

>From: xfs-bounces@oss.sgi.com [mailto:xfs-bounces@oss.sgi.com] On Behalf Of
>Linda Walsh
>Something I've long wished for and wondered why it wasn't
>there -- was the ability to edit or re-edit a typed line,
>or recall a previous line from history.
>
>I'd really find it useful to even have the ability for it to
>save previous command sessions / tool.
>

You can use the utility rlwrap to mimic this behaviour if you need it that bad.

>Given the usefulness of such, I was wondering why it had
>never been done?   Just it never rose to the top of some
>task list?  Or was there some desire to keep the tools
>less friendly and thus make them more difficult to use for
>casual use (i.e. it might have been a conscious design
>decision at some point).  Is that reasoning still a strong
>enough factor to keep things like that out of the mainline
>code?
>



This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.

http://www.encana.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Dave Chinner]

On Tue, Oct 02, 2012 at 09:44:51AM -0700, Linda Walsh wrote:
> Something I've long wished for and wondered why it wasn't
> there -- was the ability to edit or re-edit a typed line,
> or recall a previous line from history.
> 
> I'd really find it useful to even have the ability for it to
> save previous command sessions / tool.
> 
> Given the usefulness of such, I was wondering why it had
> never been done?   Just it never rose to the top of some
> task list?  Or was there some desire to keep the tools
> less friendly and thus make them more difficult to use for
> casual use (i.e. it might have been a conscious design
> decision at some point).  Is that reasoning still a strong
> enough factor to keep things like that out of the mainline
> code?

xfsprogs has had this support via readline since, well, before I
started working on XFS....

$ sudo xfs_db -r /dev/vdb
xfs_db> inode 128
(reverse-i-search)`in': inode 128
....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

Dave Chinner wrote:
> $ sudo xfs_db -r /dev/vdb
> xfs_db> inode 128
> (reverse-i-search)`in': inode 128
----
Um...When I press up-arrow, I get nothing.

When I press down arrow -- also nothing.

Try hitting home for beginning of line --
nothing.   Tried ESC to re-edit line -- nothing. (enters ^[).

What are you typing to get the above?  does it require a config somewhere?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Eric Sandeen]

On 10/2/12 4:29 PM, Linda Walsh wrote:
> 
> 
> Dave Chinner wrote:
>> $ sudo xfs_db -r /dev/vdb
>> xfs_db> inode 128
>> (reverse-i-search)`in': inode 128
> ----
> Um...When I press up-arrow, I get nothing.
> 
> When I press down arrow -- also nothing.
> 
> Try hitting home for beginning of line --
> nothing.   Tried ESC to re-edit line -- nothing. (enters ^[).
> 
> What are you typing to get the above?  does it require a config somewhere?

Do you build your own pkgs or use a distro?  IF distro, I'd file a bug.

Agreed that defaulting to on would be nice, but in Fedora & RHEL:

%configure \
        --enable-readline=yes	\
...

just FWIW.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Nathan Scott]

----- Original Message -----
> Do you build your own pkgs or use a distro?  IF distro, I'd file a
> bug.
> 
> Agreed that defaulting to on would be nice, but in Fedora & RHEL:
> 
> %configure \
>         --enable-readline=yes	\
> ...
> 
> just FWIW.
> 

$ grep enable-readline xfsprogs/debian/rules 
	  LOCAL_CONFIGURE_OPTIONS="--enable-readline=yes --enable-blkid=yes" ;


cheers.

--
Nathan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

Yeah yeah.. rub it in...
At one point suse USED to be good -- they were one of the few that
used / supported XFS...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Nathan Scott]

----- Original Message -----
> Yeah yeah.. rub it in...
> At one point suse USED to be good -- they were one of the few that
> used / supported XFS...
> 

Mmm, wasn't trying to pass judgement there - I'm sure the OpenSuSE
package maintainer will take a patch to enable it in the spec file
there if its not in place.

cheers.

--
Nathan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

Nathan Scott wrote:
> Mmm, wasn't trying to pass judgement there - I'm sure the OpenSuSE
> package maintainer will take a patch to enable it in the spec file
> there if its not in place.
----
Wouldn't bet on it...

I tried to get them to NOT issue a disabling patch for default parallelism
in upstream sort, and they said not unless I could prove it wouldn't cause a
a hang in their build process (when it was first implemented, their algorithm
had a few problems due to default buffer sizes on linux), but that was 2 years
ago and O.Suse still won't enable it - but you can specify that you want
parallel sort with every invocation -- which doesn't help for 3rd party progs
that just call sort (like updatedb) -- unless you modify them as well..

They also don't support build packages via source on a opensuse installation ---
as it has "superfluous" packages installed, and they don't want to test for
interactions anymore.

I felt even if they wanted a cleanroom for production -- they could still do
rpmbuilds with a a clean-distro devel install as a test step that things
worked together, but it seems like they are moving away from supporting direct
development or building of packages except via a special cleaned root.

Disappointing.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[David Disseldorp]

On Tue, 2 Oct 2012 23:58:59 -0400 (EDT)
Nathan Scott <nathans@debian.org> wrote:

> 
> ----- Original Message -----
> > Yeah yeah.. rub it in...
> > At one point suse USED to be good -- they were one of the few that
> > used / supported XFS...
> > 
> 
> Mmm, wasn't trying to pass judgement there - I'm sure the OpenSuSE
> package maintainer will take a patch to enable it in the spec file
> there if its not in place.

Thanks Nathan. A bug has been raised to track this:

https://bugzilla.novell.com/show_bug.cgi?id=783510

Cheers, David

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

> 
> xfsprogs has had this support via readline since, well, before I
> started working on XFS....
---
ok... I know this isn't in my version...
> which xfs_db
/usr/sbin/xfs_db
Ishtar:law> ldd /usr/sbin/xfs_db
         linux-vdso.so.1 (0x00007fffbcb07000)
         libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003007200000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003001000000)
         libc.so.6 => /lib64/libc.so.6 (0x0000003000400000)
         /lib64/ld-linux-x86-64.so.2 (0x0000003000000000)
--- there is no libreadline

Hmmm....maybe it's a distro bug...but can't figure out why they'd turn it off...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Linda Walsh]

Any reason these default to 'no'??

  --enable-readline=yes/no Enable readline command editing default=no
  --enable-editline=yes/no Enable editline command editing default=no
  --enable-termcap=yes/no Enable terminal capabilities library default=no

some distros ... *no comment*

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled?

[Dave Chinner]

On Tue, Oct 02, 2012 at 02:34:25PM -0700, Linda Walsh wrote:
> 
> 
> Any reason these default to 'no'??
> 
>  --enable-readline=yes/no Enable readline command editing default=no
>  --enable-editline=yes/no Enable editline command editing default=no
>  --enable-termcap=yes/no Enable terminal capabilities library default=no

Lost in the mists of time, I suspect. Given that we use a configure
script, I'd guess that this could easily be detected at configure
time. Patches welcome.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled? (+attachment)

[Linda Walsh]

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

Dave Chinner wrote:
> Patches welcome.
> 
> Cheers,
> 
> Dave.
---
Gee, that's a hard one... (build and tested that it was included)...

[-- Attachment #2: config.diff --]
[-- Type: text/plain, Size: 2671 bytes --]

--- configure.in	2011-08-04 07:04:44.000000000 -0700
+++ configure.in	2012-10-02 15:28:23.342090038 -0700
@@ -18,21 +18,21 @@
 AC_SUBST(enable_gettext)
 
 AC_ARG_ENABLE(readline,
-[ --enable-readline=[yes/no] Enable readline command editing [default=no]],
+[ --enable-readline=[yes/no] Enable readline command editing [default=yes]],
 	test $enable_readline = yes && libreadline="-lreadline",
 	enable_readline=no)
 AC_SUBST(libreadline)
 AC_SUBST(enable_readline)
 
 AC_ARG_ENABLE(editline,
-[ --enable-editline=[yes/no] Enable editline command editing [default=no]],
+[ --enable-editline=[yes/no] Enable editline command editing [default=yes]],
 	test $enable_editline = yes && libeditline="-ledit",
 	enable_editline=no)
 AC_SUBST(libeditline)
 AC_SUBST(enable_editline)
 
 AC_ARG_ENABLE(termcap,
-[ --enable-termcap=[yes/no] Enable terminal capabilities library [default=no]],
+[ --enable-termcap=[yes/no] Enable terminal capabilities library [default=yes]],
 	test $enable_termcap = yes && libtermcap="-ltermcap",)
 AC_SUBST(libtermcap)
 

--- configure	2011-09-27 08:36:10.000000000 -0700
+++ configure	2012-10-02 15:45:07.911807028 -0700
@@ -1532,9 +1532,9 @@
   --disable-libtool-lock  avoid locking (might break parallel builds)
  --enable-shared=yes/no Enable use of shared libraries default=yes
  --enable-gettext=yes/no Enable alternate language support default=yes
- --enable-readline=yes/no Enable readline command editing default=no
- --enable-editline=yes/no Enable editline command editing default=no
- --enable-termcap=yes/no Enable terminal capabilities library default=no
+ --enable-readline=yes/no Enable readline command editing default=yes
+ --enable-editline=yes/no Enable editline command editing default=yes
+ --enable-termcap=yes/no Enable terminal capabilities library default=yes
  --enable-blkid=yes/no Enable block device id library default=yes
  --enable-lib64=yes/no Enable lib64 support default=yes
 
@@ -9971,7 +9971,8 @@
 if test "${enable_readline+set}" = set; then :
   enableval=$enable_readline; test $enable_readline = yes && libreadline="-lreadline"
 else
-  enable_readline=no
+  enable_readline=yes
+	libreadline="-lreadline"
 fi
 
 
@@ -9981,7 +9982,8 @@
 if test "${enable_editline+set}" = set; then :
   enableval=$enable_editline; test $enable_editline = yes && libeditline="-ledit"
 else
-  enable_editline=no
+  enable_editline=yes
+	libeditline="-ledit"
 fi
 
 
@@ -9990,6 +9992,9 @@
 # Check whether --enable-termcap was given.
 if test "${enable_termcap+set}" = set; then :
   enableval=$enable_termcap; test $enable_termcap = yes && libtermcap="-ltermcap"
+else 
+	enable_termcap=yes
+	libtermcap="-ltermcap"
 fi
 
 

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled? (+attachment)

[Dave Chinner]

On Tue, Oct 02, 2012 at 03:52:08PM -0700, Linda Walsh wrote:
> Dave Chinner wrote:
> >Patches welcome.
> >
> >Cheers,
> >
> >Dave.
> ---
> Gee, that's a hard one... (build and tested that it was included)...

Actually, it's a lot more than just changing the default. If the
build system doesn't have libreadline/libedit/libtermcap installed,
the build will fail.

You need to add detection of the libraries' presence on the build
system, and then the "--enable-*" options can go away entirely.
See, for example, the way libuuid is detected in
m4/package_uuiddev.m4....

Also, libedit is only supposed to be used as a fallback option if
libreadline is not available.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled? (+attachment)

[Linda Walsh]

Dave Chinner wrote:
> On Tue, Oct 02, 2012 at 03:52:08PM -0700, Linda Walsh wrote:
>> Dave Chinner wrote:
>>> Patches welcome.
>>>
>>> Cheers,
>>>
>>> Dave.
>> ---
>> Gee, that's a hard one... (build and tested that it was included)...
> 
> Actually, it's a lot more than just changing the default. If the
> build system doesn't have libreadline/libedit/libtermcap installed,
> the build will fail.
> 
> You need to add detection of the libraries' presence on the build
> system, and then the "--enable-*" options can go away entirely.
> See, for example, the way libuuid is detected in
> m4/package_uuiddev.m4...
----
Hmmm...Oh...I thought configure did that detection.. Now I see that
was never put it and it was basically a 'manual' on/off switch
that was available.

Urk.

On top of matters, my local distrib had readline installed in a way that
it wouldn't link had libreadline.so.x.y, libreadline.so.x => libreadline.so.x.y in
/usr/lib64 but libreadline.so=>libreadline.so.x was in 
/usr/lib64/readline/libreadline.so.

???
Will have to figure out why that is and where it is supposed to be (I just
moved the soft-link from /usr/lib64/readline/libreadline.so to one dir up -- same
with libeditline...

> 
> Also, libedit is only supposed to be used as a fallback option if
> libreadline is not available.
---
Oh... thought readline did the history part and edit did the edit part...
Oi vey...

Well.. hrumph...

Will have to look this over when i get some more time.
Have a system disk upgrade to do first...

Sigh.  That I actually thought something might be simple... what an idiot!


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Why xfs_<utils> not 'readline' w/line-edit & history enabled? (+attachment)

[Dave Chinner]

On Tue, Oct 02, 2012 at 04:34:52PM -0700, Linda Walsh wrote:
> 
> 
> Dave Chinner wrote:
> >On Tue, Oct 02, 2012 at 03:52:08PM -0700, Linda Walsh wrote:
> >>Dave Chinner wrote:
> >>>Patches welcome.
> >>>
> >>>Cheers,
> >>>
> >>>Dave.
> >>---
> >>Gee, that's a hard one... (build and tested that it was included)...
> >
> >Actually, it's a lot more than just changing the default. If the
> >build system doesn't have libreadline/libedit/libtermcap installed,
> >the build will fail.
> >
> >You need to add detection of the libraries' presence on the build
> >system, and then the "--enable-*" options can go away entirely.
> >See, for example, the way libuuid is detected in
> >m4/package_uuiddev.m4...
> ----
> Hmmm...Oh...I thought configure did that detection.. Now I see that
> was never put it and it was basically a 'manual' on/off switch
> that was available.

Yup.

> Urk.
> 
> On top of matters, my local distrib had readline installed in a way that
> it wouldn't link had libreadline.so.x.y, libreadline.so.x => libreadline.so.x.y in
> /usr/lib64 but libreadline.so=>libreadline.so.x was in
> /usr/lib64/readline/libreadline.so.
> 
> ???
> Will have to figure out why that is and where it is supposed to be (I just
> moved the soft-link from /usr/lib64/readline/libreadline.so to one dir up -- same
> with libeditline...

Check what your /etc/ld.so.conf looks at - it might just be fine.

> >Also, libedit is only supposed to be used as a fallback option if
> >libreadline is not available.
> ---
> Oh... thought readline did the history part and edit did the edit part...
> Oi vey...

$ gl -n 1 d4b9ebd
commit d4b9ebda67cabf50ba9865880403a89e6b4bc3e7
Author: Nathan Scott <nathans@sgi.com>
Date:   Wed Apr 16 23:38:03 2003 +0000

    Add editline support in for cases where readline is unavailable.

> Sigh.  That I actually thought something might be simple... what an idiot!

TANSTAAFL. :/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs