Re: [Boston.pm] Perl Curses clarification

2006-06-02 Thread johns
hi ( 06.06.01 22:48 -0400 ) Chris Devers: Plan for growth. You'll be glad you did, someday. or, it will just go on that huge pile of great code that never got deployed. -- \js oblique strategy: make a sudden, destructive unpredictable action; incorporate

Re: [Boston.pm] Perl Curses clarification

2006-06-02 Thread Ted Zlatanov
On 1 Jun 2006, [EMAIL PROTECTED] wrote: Let me clarify a bit more what I need to do. We want to use $USER to verify a valid user before running the program, so this is very unlikely go on the web or have a web interface. You can tie web-based authentication to an external user database

Re: [Boston.pm] Perl Curses clarification

2006-06-02 Thread Bob Rogers
From: Ted Zlatanov [EMAIL PROTECTED] Date: Fri, 02 Jun 2006 10:22:25 -0400 On 1 Jun 2006, [EMAIL PROTECTED] wrote: Let me clarify a bit more what I need to do. We want to use $USER to verify a valid user before running the program, so this is very unlikely go on the web or

Re: [Boston.pm] Perl Curses clarification

2006-06-02 Thread Ted Zlatanov
On 2 Jun 2006, [EMAIL PROTECTED] wrote: The key is to let somebody else do as much of the authentication implementation as possible, as it's tricky and time-consuming to get right. The Unix login process can be subverted by sudo (not to mention that $USER can be set to anything, as

Re: [Boston.pm] Perl Curses clarification

2006-06-02 Thread Bob Rogers
From: Ted Zlatanov [EMAIL PROTECTED] Date: Fri, 02 Jun 2006 14:41:48 -0400 On 2 Jun 2006, [EMAIL PROTECTED] wrote: The Unix login process can be subverted by sudo (not to mention that $USER can be set to anything, as others pointed out). You should always request a

[Boston.pm] Perl Curses?

2006-06-01 Thread Janet Marie Jackson
I'm writing a command-line program to manage student grading for a course, which will run on the school's Unix boxes (it can't be put on the web for security reasons), and was debating what the best choice is to handle the user interface. Has anyone got some experience with Curses.PM and/or

Re: [Boston.pm] Perl Curses?

2006-06-01 Thread Jerrad Pierce
CLI, or terminal? Curses is a terminal interface, in which case you want Curses::UI -- H4sICNoBwDoAA3NpZwA9jbsNwDAIRHumuC4NklvXTOD0KSJEnwU8fHz4Q8M9i3sGzkS7BBrm OkCTwsycb4S3DloZuMIYeXpLFqw5LaMhXC2ymhreVXNWMw9YGuAYdfmAbwomoPSyFJuFn2x8 Opr8bBBidcc= -- MOTD on Boomtime, the 6th of Confusion, in

Re: [Boston.pm] Perl Curses?

2006-06-01 Thread Kenneth A Graves
On Thu, 2006-06-01 at 15:29, Janet Marie Jackson wrote: I'm writing a command-line program to manage student grading for a course, which will run on the school's Unix boxes (it can't be put on the web for security reasons), and was debating what the best choice is to handle the user

Re: [Boston.pm] Perl Curses?

2006-06-01 Thread David Golden
Janet Marie Jackson wrote: I'm writing a command-line program to manage student grading for a course, which will run on the school's Unix boxes (it can't be put on the web for security reasons), and was debating what the best choice is to handle the user interface. Has anyone got some

Re: [Boston.pm] Perl Curses?

2006-06-01 Thread Ted Zlatanov
On 1 Jun 2006, [EMAIL PROTECTED] wrote: I'm writing a command-line program to manage student grading for a course, which will run on the school's Unix boxes (it can't be put on the web for security reasons), and was debating what the best choice is to handle the user interface. Has anyone

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Janet Marie Jackson
Thanks to those who have answered. Let me clarify a bit more what I need to do. We want to use $USER to verify a valid user before running the program, so this is very unlikely go on the web or have a web interface. If a teaching assistant's personal account is compromised, we're really in

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Jerrad Pierce
Why not use a console-based spreadsheet? It sounds like a lot of this could be done with shell scripts (grep for users to show, etc.) -- H4sICNoBwDoAA3NpZwA9jbsNwDAIRHumuC4NklvXTOD0KSJEnwU8fHz4Q8M9i3sGzkS7BBrm OkCTwsycb4S3DloZuMIYeXpLFqw5LaMhXC2ymhreVXNWMw9YGuAYdfmAbwomoPSyFJuFn2x8

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Ben Tilly
I am going to second the suggestion to write an upload feature from a spreadsheet. You're not going to invent a better UI, and it is going to take you a lot more work. Plus there is no security issue here - anyone can do anything they want with the spreadsheet but they can only enter it into

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Steve Revilak
Date: Thu, 1 Jun 2006 20:22:27 -0400 (EDT) From: Janet Marie Jackson Subject: Re: [Boston.pm] Perl Curses clarification Thanks to those who have answered. Let me clarify a bit more what I need to do. We want to use $USER to verify a valid user before running the program, so

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Bob Rogers
From: Janet Marie Jackson [EMAIL PROTECTED] Date: Thu, 1 Jun 2006 20:22:27 -0400 (EDT) Thanks to those who have answered. Let me clarify a bit more what I need to do. We want to use $USER to verify a valid user before running the program, so this is very unlikely go on the

Re: [Boston.pm] Perl Curses clarification

2006-06-01 Thread Chris Devers
On Thu, 1 Jun 2006, Bob Rogers wrote: Please note that this does not preclude using an SQL database. [...] Of if you're hell-bent on CSV, at least use DBD::CSV and write your application as if there's a real database engine on the other side. That way, when you come around and realize that a