You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(74) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(21) |
Feb
(14) |
Mar
(6) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(14) |
Aug
(7) |
Sep
(6) |
Oct
(2) |
Nov
(7) |
Dec
(1) |
2001 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
(12) |
Oct
(3) |
Nov
(10) |
Dec
(2) |
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
2003 |
Jan
(11) |
Feb
(1) |
Mar
|
Apr
|
May
(12) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Dan <vi5...@ya...> - 2011-08-23 08:09:06
|
On Sat, 20 Aug 2011, Dan wrote: > When running psh 1.8 (more specifically, Gentoo's psh-1.8-r1) under > Perl 5.12.3, I frequently receive the following deprecated code > warnings: > > - Using an array as a reference is deprecated at > /usr/lib/perl5/vendor_perl/5.12.3/Psh/StrategyBunch.pm line 260. > > - Use of *glob{FILEHANDLE} is deprecated at > /usr/lib/perl5/vendor_perl/5.12.3/Psh/Completion.pm line 309, <DATA> > line 185. > > Unlike bug #1161491, these warnings appear even when psh is run > without the "-w" switch. > > How can I suppress these warning messages, please? Well, answering my own question... the patch below, applied to Psh 1.8.1, makes the warnings go away. However, I can't be sure that it doesn't change any functionality, since the deprecated bits of syntax are no longer very well documented. diff -rC 3 a/lib/Psh/Completion.pm b/lib/Psh/Completion.pm *** a/lib/Psh/Completion.pm 2007-07-06 04:42:01.000000000 +0100 --- b/lib/Psh/Completion.pm 2011-08-22 19:40:36.000000000 +0100 *************** *** 309,315 **** my @subs = grep (/^\w+$/ && ($sym = $pkg . $_, defined *$sym{CODE} ! || defined *$sym{FILEHANDLE}), keys %$pkg); # Do we need a user customizable variable to ignore @packages? my @result= grep(/^\Q$text/, --- 309,315 ---- my @subs = grep (/^\w+$/ && ($sym = $pkg . $_, defined *$sym{CODE} ! || defined *$sym{IO}), keys %$pkg); # Do we need a user customizable variable to ignore @packages? my @result= grep(/^\Q$text/, diff -rC 3 a/lib/Psh/Strategy/Darwin_apps.pm b/lib/Psh/Strategy/Darwin_apps.pm *** a/lib/Psh/Strategy/Darwin_apps.pm 2007-07-06 04:42:01.000000000 +0100 --- b/lib/Psh/Strategy/Darwin_apps.pm 2011-08-22 23:47:35.000000000 +0100 *************** *** 44,50 **** sub applies { ! my $com= @{$_[2]}->[0]; if ($com !~ m/$Psh::which_regexp/) { return ''; } my $path=$ENV{APP_PATH}||'/Applications'; my @path= split /:/, $path; --- 44,50 ---- sub applies { ! my $com= ${$_[2]}[0]; if ($com !~ m/$Psh::which_regexp/) { return ''; } my $path=$ENV{APP_PATH}||'/Applications'; my @path= split /:/, $path; diff -rC 3 a/lib/Psh/Strategy/Executable.pm b/lib/Psh/Strategy/Executable.pm *** a/lib/Psh/Strategy/Executable.pm 2007-07-06 04:42:01.000000000 +0100 --- b/lib/Psh/Strategy/Executable.pm 2011-08-22 23:47:15.000000000 +0100 *************** *** 24,30 **** } sub applies { ! my $com= @{$_[2]}->[0]; my $executable= Psh::Util::which($com); return $executable if defined $executable; return ''; --- 24,30 ---- } sub applies { ! my $com= ${$_[2]}[0]; my $executable= Psh::Util::which($com); return $executable if defined $executable; return ''; |
From: Dan <vi5...@ya...> - 2011-08-20 14:40:11
|
Dear All, When running psh 1.8 (more specifically, Gentoo's psh-1.8-r1) under Perl 5.12.3, I frequently receive the following deprecated code warnings: - Using an array as a reference is deprecated at /usr/lib/perl5/vendor_perl/5.12.3/Psh/StrategyBunch.pm line 260. - Use of *glob{FILEHANDLE} is deprecated at /usr/lib/perl5/vendor_perl/5.12.3/Psh/Completion.pm line 309, <DATA> line 185. Unlike bug #1161491, these warnings appear even when psh is run without the "-w" switch. How can I suppress these warning messages, please? -- Thanks, Dan |
From: Markus P. <wa...@sp...> - 2010-09-24 06:14:46
|
On 23.09.2010, at 23:19, Gregor N. Purdy, Sr. wrote: > Widening the audience for the question... > > ---------- Forwarded message ---------- > From: Gregor N. Purdy, Sr. <gn...@ac...> > Date: Thu, Sep 23, 2010 at 9:33 AM > Subject: GitHub? > To: psh...@li... > > > All -- > > I've been using GitHub a little lately for other projects and I've been toying with the idea of moving > psh to GitHub. Looks like its a lot of manual work to convert over the repo and the tickets though... > > Any of you have an opinion one way or another? Hi Gregor I really don't have an opinion on this, wouldn't mind using GitHub. There hasn't been a lot of activity anyway :-) -- Markus Peter - wa...@sp... - http://www.spin-ag.de/ - http://www.spin.de/ SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295 Regensburg Aufsichtsratsvors.: Dr. Christian Kirnberger, Vorstände: F. Rott, P. Schmid |
From: Gregor N. P. Sr. <gn...@ac...> - 2010-09-24 05:44:19
|
All -- Here's the result of a little messing around with svn2git and github importing http://github.com/gnp/psh -- gregor |
From: Gregor N. P. Sr. <gn...@ac...> - 2010-09-23 21:19:57
|
Widening the audience for the question... ---------- Forwarded message ---------- From: Gregor N. Purdy, Sr. <gn...@ac...> Date: Thu, Sep 23, 2010 at 9:33 AM Subject: GitHub? To: psh...@li... All -- I've been using GitHub a little lately for other projects and I've been toying with the idea of moving psh to GitHub. Looks like its a lot of manual work to convert over the repo and the tickets though... Any of you have an opinion one way or another? -- gregor |
From: Peng Yu <pen...@gm...> - 2010-01-24 21:30:58
|
I want to try psh. But I don't find any tutorial on psh. If there is not one, could somebody make one. This will help new users quickly grasp psh's features. Besides of text tutorial, video tutorial may also help a lot. For example, I find the the following video for ipython. http://www.youtube.com/watch?v=FAGb_qasXBE |
From: <j.g...@st...> - 2007-12-21 08:57:35
|
From: psh...@li... on behalf of Markus Peter >> On a related note, I was wondering is there exists a perl =20 >> implemenation of Gnu Readline, since getting a compiled version to =20 >> work on a variety of platforms (I am trying to use it on 32-bit =20 >> redhat, 64-bit suse and HP) can be a royal pain, since Perl can get =20 >> rather confused, especially between 32-bit and 64-bit (I had to =20 >> compile a 32-bit version and use it on both) >=20 >=20 > Unfortunately not. There's Term::ReadLine::Perl, which psh1 even =20 > supports as far as I can remember, which still dates back to some old = > Perl4 code. The codebase of that is rather weird so no-one ever =20 > extended it with new features. The Zoidberg guys (another perl shell, = > don't know how active they are nowadays) also had an attempt at a new = > Term::Readline module called Term::ReadLine::Zoid - but I haven't had = > a look at it yet and it would probably need some support of psh to be = > useful. Zoidberg is on non-active as well, since I'm investing what little time = I have in another project. However I think the Readline code is one of the best = parts of the code we wrote for zoid. It is fairly stable and is more or less = compatible with GNU Readline. (Even including vi escape mode etc.) Regards, Jaap <pa...@cp...> |
From: Markus P. <wa...@sp...> - 2007-12-21 08:27:48
|
On 20.12.2007, at 15:53, Sam Krasnik wrote: > Hi all, > Have been using PSH for quite some time now, and figured I'd try to =20= > give back a little. I have added backticking support with variable =20 > expansion, proper escape character interpretation, fixed some of the =20= > quoting/unquoting implementation including execution windows (for =20 > example "hello"$world"how are you" didn't work before), and array =20 > expansion (@a should expand to multiple arguments but was treated =20 > like "@a", which is just one) which is useful in .psh scripts via =20 > @ARGV, and a somewhat improved parser. What would be the best way to =20= > have someone look at these changes to see if they meet whatever =20 > guidelines the PSH god(s?) desire? > > There are still some bugs that I haven't gotten around to fixing, =20 > but hope to do so soon (for example, tab completion inside =20 > directories with spaces in the their name doesn't work properly as =20 > well as some strange issues with the recursive glob operator). These =20= > kind of things get in the way when using PSH all day as my main shell! Hi Sam The psh project is pretty dead I fear: psh1 hasn't been changed in =20 years. I had also written a new, more solid and faster version from =20 ground-up called psh2 which has all the basic features of a shell but =20= most of the comfort features were not added yet. The other developers =20= are pretty busy, too, with other things, I think. Gregor is mainly =20 working with Parrot now and from the others I have not heard something =20= for a while. I wouldn't mind giving you CVS access, if you want to check in your =20 changes to psh1, but maybe Gregor should say something about that, too. > On a related note, I was wondering is there exists a perl =20 > implemenation of Gnu Readline, since getting a compiled version to =20 > work on a variety of platforms (I am trying to use it on 32-bit =20 > redhat, 64-bit suse and HP) can be a royal pain, since Perl can get =20= > rather confused, especially between 32-bit and 64-bit (I had to =20 > compile a 32-bit version and use it on both) Unfortunately not. There's Term::ReadLine::Perl, which psh1 even =20 supports as far as I can remember, which still dates back to some old =20= Perl4 code. The codebase of that is rather weird so no-one ever =20 extended it with new features. The Zoidberg guys (another perl shell, =20= don't know how active they are nowadays) also had an attempt at a new =20= Term::Readline module called Term::ReadLine::Zoid - but I haven't had =20= a look at it yet and it would probably need some support of psh to be =20= useful. --=20 Markus Peter - wa...@sp... - http://www.spin-ag.de/ - = http://www.spin.de/ SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295 =20 Regensburg Aufsichtsratsvors.: Dr. Christian Kirnberger, Vorst=E4nde: F. Rott, P. =20= Schmid |
From: Sam K. <sam...@gm...> - 2007-12-20 14:53:46
|
Hi all, Have been using PSH for quite some time now, and figured I'd try to give back a little. I have added backticking support with variable expansion, proper escape character interpretation, fixed some of the quoting/unquoting implementation including execution windows (for example "hello"$world"how are you" didn't work before), and array expansion (@a should expand to multiple arguments but was treated like "@a", which is just one) which is useful in .psh scripts via @ARGV, and a somewhat improved parser. What would be the best way to have someone look at these changes to see if they meet whatever guidelines the PSH god(s?) desire? There are still some bugs that I haven't gotten around to fixing, but hope to do so soon (for example, tab completion inside directories with spaces in the their name doesn't work properly as well as some strange issues with the recursive glob operator). These kind of things get in the way when using PSH all day as my main shell! On a related note, I was wondering is there exists a perl implemenation of Gnu Readline, since getting a compiled version to work on a variety of platforms (I am trying to use it on 32-bit redhat, 64-bit suse and HP) can be a royal pain, since Perl can get rather confused, especially between 32-bit and 64-bit (I had to compile a 32-bit version and use it on both) In any case, thanks a lot to all for a great idea and implementation --sam |
From: Gregor P. <gr...@fo...> - 2007-07-06 03:38:51
|
All -- I have disabled write access to CVS for all developers, and I've migrated the repository to Subversion. Regards, -- Gregor |
From: Scott T. H. <shi...@al...> - 2006-07-06 14:41:42
|
http://perl.com/cs/user/query/q/6?id_topic=65 On Thu, 2006-07-06 at 16:30 +0200, Gregory Machin wrote: > Ok I googled agian for 2 hours ... I still non the wiser .. I'm > looking to a howto that deals with curses in perl I dont have time to > figure out how to get it to work via c examples.. I need working > examples that I can play with and learn from ... > > On 7/3/06, Gregory Machin <gre...@gm...> wrote: > Hi > I'm a Perl and Psh newbe .. > > I would like to use psh to create a command line interface for > managing networking on my embedded devices .. sort of a CISO > cios type interface but different... > Would it work for this ? > > > > -- > Gregory Machin > > +27 72 524 8096 > > > > -- > Gregory Machin > gre...@gm... > www.linuxpro.co.za > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ psh-dev mailing list ps...@li... https://lists.sourceforge.net/lists/listinfo/psh-dev -- Scott T. Hildreth <shi...@al...> |
From: Gregory M. <gre...@gm...> - 2006-07-06 14:30:11
|
Ok I googled agian for 2 hours ... I still non the wiser .. I'm looking to a howto that deals with curses in perl I dont have time to figure out how to get it to work via c examples.. I need working examples that I can play with and learn from ... On 7/3/06, Gregory Machin <gre...@gm...> wrote: > > Hi > I'm a Perl and Psh newbe .. > > I would like to use psh to create a command line interface for managing > networking on my embedded devices .. sort of a CISO cios type interface but > different... > Would it work for this ? > > > -- > Gregory Machin > > +27 72 524 8096 > -- Gregory Machin gre...@gm... www.linuxpro.co.za |
From: Gregory M. <gre...@gm...> - 2006-07-03 13:50:10
|
Hi I'm a Perl and Psh newbe .. I would like to use psh to create a command line interface for managing networking on my embedded devices .. sort of a CISO cios type interface but different... Would it work for this ? -- Gregory Machin +27 72 524 8096 |
From: Pratap R. <rm...@re...> - 2005-10-02 19:38:30
|
=A0=0AHi,=0AI am calling a C library function from a Perl script( using SW= IG ).=0AThe routine prints some information on the monitor.I want to know,h= ow to capture this data that is output on the monitor i.e basically I want = to implement the command substitution.I can do a fork and then create a pip= e and redirect the STDIN.But is there any other method other than this.My p= roject has a restriction that I cannot use fork.I also tried duping STDOUT = itself to a file and then =0Arestoring STDOUT back .This works but this is = not a clean solution.=0AIs it possible to directly read the contents printe= d on the monitor ?=0A=0A=0AThanks for any help=0APratap=0A |
From: Allan F. <pe...@af...> - 2005-09-24 21:05:35
|
On Mon, Sep 19, 2005 at 02:50:57AM -0000, Pratap Ramachandra wrote: > ? > ? > Hi , > I am currently exploring the features offered by Perl Shell.I have a query . > Does Perl Shell support auto-completion of commands ?( for eg :- in the shell prompt we have a feature by which we can use TAB for automatic completion.Is there anything similar in Perl Shell).If so how to use this feature ? > Yes, psh supports this. man pshcomplete > Thanks for any help > Pratap -- Allan Fields |
From: Pratap R. <rm...@re...> - 2005-09-19 02:50:42
|
=A0=0A =A0=0AHi ,=0AI am currently exploring the features offered by Perl = Shell.I have a query .=0ADoes Perl Shell support auto-completion of command= s ?( for eg :- in the shell prompt we have a feature by which we can use TA= B for automatic completion.Is there anything similar in Perl Shell).If so h= ow to use this feature ?=0A=0AThanks for any help=0APratap |
From: Allan F. <pe...@af...> - 2005-06-02 12:51:12
|
OK, finally, I put up yapc.ca 2003 video. I digitized them while I was doing BSDCan 2005 proceedings [http://afields.ca/bsdcan/2005/ ]. It's online now at http://afields.ca/yapc.ca/ Talks include one on perl shells that I did. In retrospect there is lots of room for improvement in the talk. If I did it again I'd certainly be less nervous, as it's no big deal delivering a presentation (but that was my 1st one at a conference). Also I'm different now than even just 2 years ago. And yes I have been hacking Zoidberg some, but time was limited during/after BSDCan. Time permitting both shells could see contributions.. I'll keep the list up to date on progress. -- Allan Fields |
From: Allan F. <pe...@af...> - 2005-05-01 17:18:47
|
On Thu, Apr 14, 2005 at 02:40:00PM -0400, Michael Graham wrote: > > > > If anyone wants to submit a talk for YAPC::NA on Zoid, psh, Fry or Perl > > > Shells in general for YAPC::NA, please do so! The deadline is fast > > > approaching. The call for papers link is here: > > > > > > http://www.yapc.org/America/cfp-2005.shtml > > > > I can submit one, unless someone else wants to present on the topic. > > I've been meaning to finish off/expand/redo 'Exploring Perl Shells' > > anyway. The tutorial material will finally be included! :) > Submitted, but I assume not accepted in the schedule. That's fine, but I'll aim to update the material anyway.. and I'll post to the list when I'm done. (Time) > As I see it, the three big selling points of perl shells are (1) being > able to hack new features into your own shell, (2) the power of using > perl at the command line, and the (3) power of having different command > line "modes" integrated into one shell (like SQL mode. Doesn't one of > the perl shells have an SQL mode? Or did I dream that?) > > And the big selling point about perl at the command line is being able > to pipe stuff through blocks of perl code: > > psh% cat /var/log/apache/error | { /Thu Nov 25/ }g > > psh% cat /etc/passwd | { @fields = split /:/; print $fields[0], "\n" }q > > psh% sub piglatin { > > chomp $_[0]; > > return $_[0] =~ /^([bcdfghjklmnpqrstvwxyz]+)(.*)/i ? > > "$2$1ay\n" : "$_[0]ay\n" > > } > > psh% ls | { print piglatin($_) }q > > Even using psh as a secondary shell for calculations, etc. can give you > some of the benefits without the hassle of relearning all your habits. > Can I get the abstract I submitted using the online form, I don't think I saved a local copy. > Michael > ----------------------------------------------------------------------- > Michael Graham <ma...@th...> > > YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - na...@ya... > ----------------------------------------------------------------------- Thanks, -- Allan Fields |
From: Allan F. <pe...@af...> - 2005-04-21 00:49:09
|
On Wed, Apr 20, 2005 at 11:01:44PM +0200, Jaap Karssenberg wrote: > Somethings seems to be wrong with rcs locks can't figure it out > so I disabled rcs backup for the time being ... I'll have a look > at it in the weekend when I'm in the same physical location as the > server. >=20 > Impressive list you put there; I see a lot of Good Things there. >=20 > Some random thought: >=20 > Full bash compatibility (in the sense of being able to run bash > scripts) would be very nice, but will also involve a lot of bloat. > Probably this should be a non-default plugin. Also a simpe plugin > could be written that exports bash flow control (if, case, ..) as > builtins ... yes I thought about this when I designed the parser > :) Well you don't have to do everything, I'm sure over time patches will start coming in to fill out the feature set/grammar too. I've updated BrainStorm to indicate this preference. I might use the wiki as an active check list, since i'd do it in vi locally anyway.. > But for example bash variable like "${par:=3D..}" don't seem really > usefull in a perl shell. But if we want to use existing scripts, many make extensive use of parameter expansions. Even if there is a better way to do it in zoid/perl, the idea is to give Bourne users the old way too, until they transition. (TMTOWTDI) > 'Autoresume support' could you clarify that item ? Smart autoresume support. Autoresume support will enable a user to resume existing (bg/stopped) jobs given similar or identical commandline and similarly w/ string based jobspecs include % (prefix) and %? (substring). Autoresume just omits the need to use a jobspec and instead checks each commandline against existing matches. For example: zoid$ auto_resume=3Dprefix zoid$ vi test.txt test ~ =1A [4]+ Stopped vi test.txt zoid$ vi toast.txt toast ~ =1A [5]+ Stopped vi toast.txt zoid$ fg %vi ##(Should return ambiguous, resumes: vi test.txt) zoid$ vi ##(Should return ambiguous, resumes: vi test.txt) zoid$ vi ##(Should return ambiguous, resumes: vi test.txt) zoid$ which v which: no v in PATH zoid$ v ##(Should return ambiguous, resumes: vi test.txt) zoid$ auto_resume=3Dexact zoid$ v zoid: v: command not found zoid$ auto_resume=3Dsubstring zoid$ i ##(Should return ambiguous, resumes: vi test.txt) ##(Notice how args don't matter yet:) zoid$ auto_resume=3Dprefix zoid$ vi t ##(Should return ambiguous, resumes: vi test.txt) test ~ =1A zoid$ %vi te test :q zoid$ fg %vi t ##Finally some toast toast :q zoid$ Not only auto_resume support, but also job_spec needs to be expanded to the full context of the commandline where options are part of the spec. Here's a typical mixed up job example from a bash shell in my remote session: (On this host w3m isn't built with tab support.. but I could just as easily be editing numerous config files and other admin tasks on a different tty, eventually jobs stack up, even w/ screen) bash-2.05[af...@af...:355.4(p8)](14) Wed 20 193543 /> jobs [2] Stopped w3m http://www.fsmware.com/xenofreebsd [6] Stopped w3m afields.ca/yapc (wd: /mirror) [7] Stopped w3m http://zoidberg.student.utwente.nl (wd: = /mirror) [8] Stopped sudo vi /site/bin/periodic/mirror.sh (wd: /m= irror) [9]+ Stopped w3m http://www.yapc.org/America/cfp-2005.shtm= l (wd: /mirror) [11] Stopped man gpg (wd: /mirror) [12] Stopped gpg --edit-key bs...@af... (wd: /mirror) [17] Stopped w3m www.dictionary.com (wd: /mirror) [20] Stopped w3m http://www.digital-copyright.ca (wd: /m= irror) [23]- Stopped less -f /var/log/apache/afields.ca (wd: /mi= rror) [24] Stopped mutt bash-2.05[af...@af...:355.4(p8)](14) Wed 20 193544 /> fg %w3m af bash: fg: ambigious job spec: w3m bash-2.05[af...@af...:355.4(p8)](14) Wed 20 193555 /> fg %w3m http:/= /www.d bash: fg: ambigious job spec: w3m bash-2.05[af...@af...:355.4(p8)](14) Wed 20 193632 /> fg %w3m www.d # If resuming on prefix/substring of commandline: # The first should resume (fg) [6] # The first should resume (fg) [20] # The first should resume (fg) [17] # Existing/future: auto_resume=3D resume previous job/invocation in shell exact: full command (regardless of args) resumes previous invocation in = shell prefix: prefix of command (regardless of args) resumes previous invocati= on substring: substring of command (regardless of args) resumes previous in= vocation suffix: suffix of command (regardless of args) resumes previous invocati= on exact_commandline: full commandline (w/ args) resumes previous invocation= in shell prefix_commandline: prefix of commandline (w/ args) resumes previous invo= cation in shell substring_commandline:substring of commandline (w/ args) resumes previous= invocation in shell suffix_commandline: suffix of commandline (w/ args) resumes previous invo= cation in shell # I figure we don't need *_args since substring_commandline covers that Notice how even bash isn't yet smart enough to take the % jobspec over both the command and arguments (full commandline) meaning duplicate jobs w/ the same command are hard to discern. However it is smart enough to do: $fg %?zoid ##[7] $fg %?dict ##[17] On ambiguous spec instead of choosing the first, present a short menu: % fg %w3m<TAB> # Same with tab, let it be completed $ fg %w3m [2] Stopped w3m http://www.fsmware.com/xenofreebsd [6] Stopped w3m afields.ca/yapc (wd: /mirror) [7] Stopped w3m http://zoidberg.student.utwente.nl (wd: = /mirror) [9]+ Stopped w3m http://www.yapc.org/America/cfp-2005.shtm= l (wd: /mirror) [17] Stopped w3m www.dictionary.com (wd: /mirror) [20] Stopped w3m http://www.digital-copyright.ca (wd: /m= irror) > 7 > D-Bus integration, now thats a topic that gets me all warm and > fuzzy inside :) We had several attempts at IPC for zoid since the > very first version, and I believe that this could be the killer > feature that could get zoid to flourish outside the perl community. > [..] > Please let me know if you have a detailed idea of how this should > work. Of course this also should be a plugin. I'll try to ellaborate on this as a part of my UNUF work (Future: what's UNUF?) D-BUS, given it can be integrated into console apps as well as X11 desktop apps w/o a huge bloat/overhead to the code, might make sense to implement advanced features such as session management. > The kill and killall commands you propose could be implemented > very easily, our getOpt lib can handle hash arguments although with > a slightly different syntax. I think "kill -9 user=3D"afields" tty=3Dttyp9 > state=3DT" would do nicely. Also state might have full names: T could be "bg" and use "run", "sleep", "= swap" > Thanks for your input ! > > On Wed, April 20, 2005 21:25, Allan Fields said: > > Software error: > >=20 > > ci -q -l -m"66.11.173.111" database/BrainStorm metabase/rcs/BrainStorm,v > > failed: 256 in /mnt/raid/www/zoidberg/wiki at > > /usr/lib/perl5/site_perl/5.8.6/CGI/Kwiki/Backup/Rcs.pm line 113. > >=20 > > For help, please send mail to the webmaster > > (j.g...@st...), giving this error message and the > > time and date of the error. >=20 > -- Pardus >=20 >=20 --=20 Allan Fields |
From: Allan F. <pe...@af...> - 2005-04-14 22:46:08
|
On Thu, Apr 14, 2005 at 02:05:17PM +0200, Jaap Karssenberg wrote: > On Thu, April 14, 2005 4:18, Allan Fields said: > > My take is that wider adoption as a user shell will require the > > following: > > > > - Convincingly Bourne and/or CSH like compatibility: it must be > > intuitive to make the initial switch. (One test would be to see how long > > it takes an experienced bash or tcsh user to master the basics including > > job control, and redirection.) > > In zoid and psh simple commansd are the same as in bash, in zoid job control and redirections look like bash (IIRC this is true also for psh) so there should no problem for bash users. It's mostly the small differences that tend to initially confuse, I could try doing a full set of userside tests based on all the typical commandlines and shortcuts I use in bash. In zoid and psh these are very easy to correct as both are highly configurable. In all shells aliases can be drawn too. One note is in psh and zoid: /^%(.*)/ doesn't work for job control by default, for those bash users who developed that as a habit, it might be desired changed. Because % is a perlism, it's an evaluation strategy where a decision is made one way or the other. Zoidberg$ % Zoidberg$ %- Zoidberg$ %1 Zoidberg$ set debug Zoidberg$ %+ Zoidberg: 927: going to call sub: _do_perl ^^^^^^^^^^^^^ Zoidberg: 982: going to eval perl code: << '...' package Zoidberg::Eval; no strict; %+ ... # Like ksh I suppose: Zoidberg$ fg % Sorry if I sound so picky, but these smaller things matter to an initial impression. Now if we get beyond them, then it can be seen why Perl shells offer a lot of benefits. It may be necessary to loop around at ground level from a while before taking off. I compare it to why people use bash over say tcsh, tcsh itself has lots of features just like bash, some would argue it's better, some not: but it's a different type of user experience, and what you are used to. The key is it doesn't have to be one (user experience) or the other with multiple evaluation strategies or syntactical "modes", which both Perl shell projects aim to support. > > - Provably stable/mature performance: with > > bash it's known that most builtins/internals provide reliable, consistent > > behavior regardless of the system, less significant bugs/platform issues > > have also been worked out. > > When I release a stable version of zoid it will have a large test suite testing every aspect of the program. Of course weeding out bugs for exotic platforms will only happen when there are users there reporting bugs. Right, and it's no fault of the authors that the newer shells aren't as mature at this point. I'm working on the ReadLine bug, and I quickly read over the full Zoidberg code last night including the parser. ;) I also noted that if I have my own .zoidrc, it's necessary to change some lines to avoid pushing the startup/shutdown message multiple times (for example) as it reads both the global /usr/local/etc/zoidrc and ~/.zoidrc files respectively. So that could be a feature, but I'll play with it some more to see if it then becomes harder to exclude the global defs. > Yes a very large test suite indeed and then run it for as many as setups as possible. My normal release procedure for zoid includes running the current test suite with at least 5.8.* and 5.6.* (where * is the version in my linux distribution at the time). I have patched zoid for some know bugs with certain perl versions, but so far my test suite doesn't cover everything. > > One problem is that as we rely on other CPAN modules there is always a risk of someone else breaking the compatibility without telling us; ideally the core functions should not rely on other modules, but I'm not sure if that is entirely possible. Of course this also opens up the functionality for other cpan users or even other perl shells, for example you could use psh with zoid's readline code :) > > Further along in the development curve many of these potential pitfalls > > could be eliminated in both zoid and psh/psh2. > > Is there any active developement for psh/psh2 at the moment ? I didn't check for some time but I didn't notice any releases for the last year(s). As always I'm open to ideas about collaboration if there is someone writing code on the other side. Let me just note quickly I'm selecting neither /zoid(?:berg)?|psh2?/i in preference, but doing the rounds one at a time. > > That could be included in a presentation, perhaps a nice table that could > > be printed off. Maybe a cross-ref for common commands, like the vi key > > chart for beginners. > > So which features need to be in the table? I recall there is some sort of list in the old psh documentation comparing psh to other (smaller) perl shells, but I don't think that suffices to compare perl shells with bash/ksh/zsh/etc. > Zoid and Psh both have job control, pipelines, redirection, expansions, readline support etc.; the real differences are in the design of the program, but that can't be easily put in a chart. It's the practical/pragmatic which I was concerned with, any syntax changes, etc. That would do well being documented (if not just fixed right away) somewhere including the set of underlying functionality whether it be of union/intersection/subset/superset. If it comes to the point where it is almost indistinguishable to Bourne syntax, which I wanted to do in psh too, then such a chart may be of less utility. As we get further along: f(X) : [bash {psh (zoid ] } ) => f'(X): [bash(zoidr{psh ] ) } > -- Pardus -- Allan Fields |
From: Michael G. <ma...@th...> - 2005-04-14 19:08:40
|
> One problem is that as we rely on other CPAN modules there is always a > risk of someone else breaking the compatibility without telling us; > ideally the core functions should not rely on other modules, but I'm not > sure if that is entirely possible.=20 Because you can get locked out of your account if your shell breaks, there may be justification for extreme and unusual measures to protect the shell and its library. One possibility is to use PAR and have a self contained executable. Another is to keep a private CPAN tree and have the main shell exectuable set @INC to this tree. Actually, PAR may be able to do this too. Obviously these are wishlist items for some future release. > >> Since none of these problems are good excuses, I really should get off > >> my bash and back into perl shells. Now does someone have a handy > >> feature-comparison chart for psh and zoid? :) =2E.. > So which features need to be in the table? I recall there is some sort > of list in the old psh documentation comparing psh to other (smaller) > perl shells, but I don't think that suffices to compare perl shells with > bash/ksh/zsh/etc. Zoid and Psh both have job control, pipelines, > redirection, expansions, readline support etc.; the real differences are > in the design of the program, but that can't be easily put in a chart. I was mainly thinking about pros and cons of one shell syntax vs. the other. Obviously when you start trying to parse both perl and shell syntax at the same time there are tradeoffs and edge cases and places where the parser guesses wrong. Michael ----------------------------------------------------------------------- Michael Graham <ma...@th...> YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - na...@ya... ----------------------------------------------------------------------- |
From: Michael G. <ma...@th...> - 2005-04-14 18:38:20
|
> > If anyone wants to submit a talk for YAPC::NA on Zoid, psh, Fry or Perl > > Shells in general for YAPC::NA, please do so! The deadline is fast > > approaching. The call for papers link is here: > > > > http://www.yapc.org/America/cfp-2005.shtml > > I can submit one, unless someone else wants to present on the topic. > I've been meaning to finish off/expand/redo 'Exploring Perl Shells' > anyway. The tutorial material will finally be included! :) Great! Personally, I don't think it needs to be an exhaustive survey of perl shells and their features. I think the topic would make a really good 'teaser' talk, just to get people excited about the possibility of using perl shells. The standard talk length at YAPC this year is 20 minutes, which is really only just long enough to introduce a topic and open it up for conversation. But having a comprehensive online resource to back up the talk would be great. As I see it, the three big selling points of perl shells are (1) being able to hack new features into your own shell, (2) the power of using perl at the command line, and the (3) power of having different command line "modes" integrated into one shell (like SQL mode. Doesn't one of the perl shells have an SQL mode? Or did I dream that?) And the big selling point about perl at the command line is being able to pipe stuff through blocks of perl code: psh% cat /var/log/apache/error | { /Thu Nov 25/ }g psh% cat /etc/passwd | { @fields = split /:/; print $fields[0], "\n" }q psh% sub piglatin { > chomp $_[0]; > return $_[0] =~ /^([bcdfghjklmnpqrstvwxyz]+)(.*)/i ? > "$2$1ay\n" : "$_[0]ay\n" > } psh% ls | { print piglatin($_) }q Even using psh as a secondary shell for calculations, etc. can give you some of the benefits without the hassle of relearning all your habits. Michael ----------------------------------------------------------------------- Michael Graham <ma...@th...> YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - na...@ya... ----------------------------------------------------------------------- |
From: Jaap K. <j.g...@st...> - 2005-04-14 12:02:55
|
On Thu, April 14, 2005 4:18, Allan Fields said: > My take is that wider adoption as a user shell will require the > following: > > - Convincingly Bourne and/or CSH like compatibility: it must be > intuitive to make the initial switch. (One test would be to see how lon= g > it takes an experienced bash or tcsh user to master the basics includin= g > job control, and redirection.) In zoid and psh simple commansd are the same as in bash, in zoid job cont= rol and redirections look like bash (IIRC this is true also for psh) so t= here should no problem for bash users. > - Provably stable/mature performance: with > bash it's known that most builtins/internals provide reliable, consiste= nt=20 > behavior regardless of the system, less significant bugs/platform issue= s > have also been worked out. When I release a stable version of zoid it will have a large test suite t= esting every aspect of the program. Of course weeding out bugs for exotic= platforms will only happen when there are users there reporting bugs. My current strategy is to fork of functional blocks of zoid into their ow= n modules; so far Term::ReadLine::Zoid is the best example of this. This = forces the program to use clearly defined interfaces between various part= s and also allows for better testing of the independent modules. - At least the equivalent or better > functionality of todays modern shells in most respects: if some areas a= re > lacking. For zoid we started with the functionality specified by POSIX and then st= arted adding the things we liked in other shells. As more people try it m= ore feature requests might come in, this measn active support and develop= ment in needed for a long time. > - The shell shouldn't/can't break with changes to perl > installation ( If one uses CPAN to upgrade some other modules and/or pe= rl, > this shouldn't interfere with both running and future shells, if it doe= s > then the shells foundations aren't stable enough for general use. ) > - Therefore: Well tested backward/forward compatibility between perl an= d=20 > the shell Yes a very large test suite indeed and then run it for as many as setups = as possible. My normal release procedure for zoid includes running the cu= rrent test suite with at least 5.8.* and 5.6.* (where * is the version in= my linux distribution at the time). I have patched zoid for some know bu= gs with certain perl versions, but so far my test suite doesn't cover eve= rything. One problem is that as we rely on other CPAN modules there is always a ri= sk of someone else breaking the compatibility without telling us; ideally= the core functions should not rely on other modules, but I'm not sure if= that is entirely possible. Of course this also opens up the functionalit= y for other cpan users or even other perl shells, for example you could u= se psh with zoid's readline code :) > - Mechanical aspects: the feasibility could be effected by footprint > and other mechanical aspects. A perl shell will always have a considerably larger footprint then for ex= ample bash. This is due to the nature of perl, nothing to do about it. Ma= ybe it gets better when we can compile to parrot byte code or something := ) > Further along in the development curve many of these potential pitfalls > could be eliminated in both zoid and psh/psh2. Is there any active developement for psh/psh2 at the moment ? I didn't ch= eck for some time but I didn't notice any releases for the last year(s). = As always I'm open to ideas about collaboration if there is someone writi= ng code on the other side. ... 8< ... >> Since none of these problems are good excuses, I really should get off= =20 >> my bash and back into perl shells. Now does someone have a handy=20 >> feature-comparison chart for psh and zoid? :) >=20 > That could be included in a presentation, perhaps a nice table that cou= ld > be printed off. Maybe a cross-ref for common commands, like the vi key > chart for beginners. So which features need to be in the table? I recall there is some sort of= list in the old psh documentation comparing psh to other (smaller) perl = shells, but I don't think that suffices to compare perl shells with bash/= ksh/zsh/etc. Zoid and Psh both have job control, pipelines, redirection, expansions, r= eadline support etc.; the real differences are in the design of the progr= am, but that can't be easily put in a chart. -- Pardus |
From: Allan F. <pe...@af...> - 2005-04-14 02:18:44
|
On Wed, Apr 13, 2005 at 03:04:19PM -0400, Michael Graham wrote: > > > > (For my own part, I've always had a fascination with perl shells (I used > > > psh for awhile, but I'm still on bash at the moment. Hoping (as always) > > > to switch to Zoid or psh in the near future) > > > > So tell us what is holding you back to get rid of bash and maybe we can fix it for you :) My take is that wider adoption as a user shell will require the following: - Convincingly Bourne and/or CSH like compatibility: it must be intuitive to make the initial switch. (One test would be to see how long it takes an experienced bash or tcsh user to master the basics including job control, and redirection.) - Provably stable/mature performance: with bash it's known that most builtins/internals provide reliable, consistent behavior regardless of the system, less significant bugs/platform issues have also been worked out. - At least the equivalent or better functionality of todays modern shells in most respects: if some areas are lacking. - The shell shouldn't/can't break with changes to perl installation ( If one uses CPAN to upgrade some other modules and/or perl, this shouldn't interfere with both running and future shells, if it does then the shells foundations aren't stable enough for general use. ) - Therefore: Well tested backward/forward compatibility between perl and the shell - Mechanical aspects: the feasibility could be effected by footprint and other mechanical aspects. Further along in the development curve many of these potential pitfalls could be eliminated in both zoid and psh/psh2. > At the moment? Just time. In the past, the reasons that I stopped > using psh were: > > * I was using too many systems that only had bash (and my brain hurt > trying to switch between psh and bash all the time). These days, > I don't use many systems that I can't install perl modules on. Perl has become increasingly standard due to it's use in the auto* and other build tools. So if packages/ports/$whatever were to exist advertising the perl shell (an entry point for install) and people experimented w/ the shell and found it stable, they might then start to employ it for some tasks. > * Too often I would hack psh and break it to the point that I could no > longer log in. This taught me the important lesson: don't make your > perl shell your default shell; run it from bash when you log in. > (This is less of a hassle for me these days, since I use screen) You can create a user for perl shells, but then if you desire it the primary login shell then perhaps there needs to be two versions of the shell on the machine: one test and one dev. I've got my windows too: 22 psh $ 55 zoid $ The screen default #define MAXWIN 40 is far too small, in my experience. ;) But then how do you hack screen from with-in a screen? 1 screen-hack $ 2 afields-admin $ 3 bash-hack $ .. This is a bigger issue that scales to any critical infrastructure/software tools that are themselves supporting the work: Operating Systems Screen Multiplexors (I loath the dungeon collapse and similar syndromes) Shells Build Tools Compilers It takes someone to risk breaking their environment, best done with a mix of stable/devel. > * psh was quick to use, but took forever to start up > (Also less of a hassle due to screen) > > Since none of these problems are good excuses, I really should get off > my bash and back into perl shells. Now does someone have a handy > feature-comparison chart for psh and zoid? :) That could be included in a presentation, perhaps a nice table that could be printed off. Maybe a cross-ref for common commands, like the vi key chart for beginners. > Michael > > > ----------------------------------------------------------------------- > Michael Graham <ma...@th...> > > YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - na...@ya... > ----------------------------------------------------------------------- -- Allan Fields |
From: Allan F. <pe...@af...> - 2005-04-14 01:08:23
|
On Wed, Apr 13, 2005 at 01:56:48PM -0400, Michael Graham wrote: > > > And I'll report any findings to the list/on my pages... that > > Hacking Perl Shells paper is still waiting to be finished. > > > > YAPC::Canada no longer exists so far, but there is always YAPC::NA. > > And this year YAPC::NA is in Toronto, so it's not too far for you Ottawa > folk. :) Cool, I've put the date on my calendar. I copied the Ottawa.pm list which I think is still running anyway. I have a vehicle so can do car pooling from Ottawa, if I'm heading out that way. > If anyone wants to submit a talk for YAPC::NA on Zoid, psh, Fry or Perl > Shells in general for YAPC::NA, please do so! The deadline is fast > approaching. The call for papers link is here: > > http://www.yapc.org/America/cfp-2005.shtml I can submit one, unless someone else wants to present on the topic. I've been meaning to finish off/expand/redo 'Exploring Perl Shells' anyway. The tutorial material will finally be included! :) I think it makes it a bit dry to discuss the shells w/o a demonstration. I'd have zoid and psh running on my laptop for the presentation, fixing any bugs before hand, of course. ;) I'll want to time and refocus my previous talk, as IIRC I went some over time. If more material already exists, I can put it up on my pages and all though they've been getting kind of stale, I do plan to sync with new material some time this week. > Michael > > ----------------------------------------------------------------------- > Michael Graham <ma...@th...> > > YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - na...@ya... > ----------------------------------------------------------------------- -- Allan Fields |