barry@pico.math.ucla.edu (Barry Merriman) (06/03/91)
In our effort to make NeXTSTep more UNIX-userfriendly, we should
catalog our current difficulties, and see if they can't be resolved
either via some Apps, or some added functionality from NeXT.
Most places where UNIX clashes with NeXTStep manifest themselves
as an unnatural need to open a Terminal. In the best of all possible
NeXTWorlds, one would only need a Terminal to login into
non-NeXT machines; I consider this to be the only valid use.
Here are the *invalid* uses for Terminals that I do most frequently,
which point toward some deficiency of NeXTStep.
(1) su-ing to ``root''
(2) anything that I need to do as root
(3) tar/untar a file
(4) compress/uncompress a file
(5) grep-ing a file
(6) looking/getting inside of an <Appname>.app directory,
mailboxes, and other directories that the browser can't
see inside of (I hate when that happens!)
(7) ftp-ing
(8) compiling
(9) doing ``ls -a'' to see files starting with a ``.'',
or to look in UNIX directories like /etc, etc.
(I know the UNIX Expert setting in Preferences toggles this,
but its a pain to have to use Preferences to change it)
(10) running shell scripts
Here is another major UNIX-NeXTStep clash:
(11) The GUI is not accesible from shell scripts
What are your favorite UNIX-NeXTStep clashes?
--------------------
Here are the sort of fixes I would like to see:
(1),(2): a graphical ``su'', that allows you to change to another user's
Workspace, including root.
(3),(4),(5),(8),(10) a UNIXCommand App that would give one simple
GUI access to UNIX commands, with the benfit of GUI amenities
like browsers for selecting files, menues for command line
options & convenience, dwrites for defaults, drag-and-drop
features.
(6), (9) The UNIX Expert display mode should be able to see inside
of .app directories, and UNIX Expert mode should be somewhere
on the Workspace Menu.
(7) ftp is being GUI-ized by the ``Touch'' App, which will give one
browser-like interface to ftp; currently in beta mode at NeXT, I've
heard. Yeah!
As for (11), I hope they eventually extend the GUI and IB to
use with shell scripts. After all, just as shell scripts are
often much more convenient for little taskes than c programs,
so would GUI shell scripts be much more convenient than
full Apps for many little tasks. At the very least, shell scripts
should be able to open input windows, so that one needn't have a window
open to run a shell script that takes input.
-------------------
Any other examples to add to the list, or proposed fixes?
Maybe at some point we can petition NeXT to address those
concerns that involve them (like 11).
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)glenn@heaven.woodside.ca.us (Glenn Reid) (06/04/91)
Barry Merriman writes > (6) looking/getting inside of an <Appname>.app directory, > mailboxes, and other directories that the browser can't > see inside of (I hate when that happens!) Use command-O (capital O) to get inside these packages. It's called "Open as Folder" in the menu. > (8) compiling You can sort of run "Make" from interface builder, but I'll agree that it's less than perfect. > (9) doing ``ls -a'' to see files starting with a ``.'', > or to look in UNIX directories like /etc, etc. > (I know the UNIX Expert setting in Preferences toggles this, > but its a pain to have to use Preferences to change it) Just start typing the path (with . or /etc or whatever) and the "Finder" pops up to help you complete the path. It also jumps into UNIX Expert mode if you've typed a leading . or a path that is hidden. > (10) running shell scripts Just double-click them, unless they require arguments. All in all, you're right about the deficiencies, and I agree with you. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-326-2974 (NeXTfax 326-2977)
eps@toaster.SFSU.EDU (Eric P. Scott) (06/04/91)
In article <1991Jun3.050426.28427@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: >(1) su-ing to ``root'' I have little sympathy here >(2) anything that I need to do as root Ditto >(3) tar/untar a file Installer >(4) compress/uncompress a file Several third-party products (and archive submissions) >(5) grep-ing a file Use Edit >(6) looking/getting inside of an <Appname>.app directory, > mailboxes, and other directories that the browser can't > see inside of (I hate when that happens!) Try Command-Shift-O >(7) ftp-ing Several people are said to be working on this >(8) compiling One click in InterfaceBuilder >(9) doing ``ls -a'' to see files starting with a ``.'', > or to look in UNIX directories like /etc, etc. > (I know the UNIX Expert setting in Preferences toggles this, > but its a pain to have to use Preferences to change it) Aww... >(10) running shell scripts Just double-click on them >Here is another major UNIX-NeXTStep clash: > >(11) The GUI is not accesible from shell scripts Sure it is... but I don't recommend it :-) >What are your favorite UNIX-NeXTStep clashes? There's entirely too much focus on "applications for morons," e.g. NetMangler and UserMangler, which provide no feedback about what they're REALLY doing so you don't LEARN anything, and can't fix things when they break. Whenever someone begins a post with "I have a NetInfo Network" or "I have a non-NetInfo Network" I cringe... These guys haven't got a clue. When I set up machines, I decided how *I* wanted them configured, not from what a braindead GUI app thought was "good enough." I'm on the Internet--I need interoperability with a wide variety of platforms, conformance with de facto standards, reliability, and security. You don't get that from clicking buttons. You get that from using the lower-level tools, by editing rc scripts, customizing sendmail configurations, and by replacing defective executables with working versions. I've got hundreds of people (some of them... malevolent) beating on NeXTs every day, and they stay up, and they do what they're supposed to. People get their work done, users are happy. The NeXT is a damn fine UNIX box, and don't you forget it. -=EPS=- -- Don't let schoolin' interfere with your education. Don't let NextStep interfere with your UNIX experience.
mja@acd4.acd.com ( Mike Allard ) (06/05/91)
In article <1991Jun3.050426.28427@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: [stuff deleted] >Here is another major UNIX-NeXTStep clash: > >(11) The GUI is not accesible from shell scripts > [more stuff deleted] > >As for (11), I hope they eventually extend the GUI and IB to >use with shell scripts. After all, just as shell scripts are >often much more convenient for little taskes than c programs, >so would GUI shell scripts be much more convenient than >full Apps for many little tasks. At the very least, shell scripts >should be able to open input windows, so that one needn't have a window >open to run a shell script that takes input. When NeXT originally sent out System Release 2.0, they included an Upgrade2.0.app. The interesting thing about Upgrade2.0.app was that the majority of the logic of the program was not stored in the executable, but in '.tcl' files. Tcl looks like it is a cross between csh and C. These scripts were interpreted at runtime. I know, because I needed to change the functionality of the Upgrade app so that it correctly upgraded our NetBoot clients (which were setup in a slightly nonstandard way, in /clients/hosts instead of in /clients, but that's not the point.) The point is: these tcl scripts interacted with NextStep in some rather interesting ways, by doing such things as popping up panels, creating matrices, reading the state of buttons, and such. This is more or less the kind of functionality that Barry is describing, and exactly what many of us would like to use, yes? Tcl had such neat constructs as arrays and subroutines and private data structures (I think). And, it let you play with NextStep from an interpreted script, rather than from a compiled executable. Any clues on this tcl product, or its NeXT implementation? I am very interested, as are probably quite a few others. Let me know through e-mail if you have any info on tcl. I'll post if I find anything out. Mike Allard, CS Student on Summer Internship Applied Computing Devices, Terre Haute, IN acd4!mja or mja@acd4.acd.com These postings and opinions are strictly my own and not my employers's, etc. etc.
louie@sayshell.umd.edu (Louis A. Mamakos) (06/05/91)
In article <1991Jun4.182701.5776@acd4.acd.com> mja@acd4.acd.com ( Mike Allard ) writes: >Any clues on this tcl product, or its NeXT implementation? TCL ("Tool Control Language") is available from UC Berkeley, and is a really niftly little procedural extension language that you can build into your applications. If you've ever used the "expect" program, you program it using TCL. I'd really like to see the NextStep interfaces that NeXT did to extend TCL. Its really pretty easy to add your own primitives to TCL, and that's really the point of the language. Here's the README file from the TCL distribution. I think that its available via anonymous FTP from ucbvax.berkeley.edu. Tcl by John Ousterhout University of California at Berkeley This directory contains the sources for Tcl, an embeddable tool command language. For an introduction to the facilities provided by Tcl, see the paper ``Tcl: An Embeddable Command Language'', in the Proceedings of the 1990 Winter USENIX Conference. A copy of that paper is included in this directory in Postcript form: it's in the file "usenix.ps". This file assumes that you have received a Tcl distribution and are going to use Tcl on a UNIX system; if you're running under Sprite at Berkeley, then some of the notes here may be incorrect. The documentation for Tcl is present in this directory as a set of files with ".man" extensions. The file "Tcl.man" gives an overall description of the Tcl language and facilities, and the other ".man files describe the library procedures that Tcl provides for tools to use. Read the "Tcl" man page first. To print any of the man pages, use a command like ditroff <file> where <page> is the name of the man page you'd like to print. Don't specifiy any macros. Type "make" to generate the Tcl library, and type "make tclTest" to create a simple test program that you can use to try out the Tcl facilities. TclTest is just a main-program sandwich around the Tcl library. It reads standard input until it reaches the end of a line where parentheses and backslashes are balanced, then sends everything it's read to the Tcl interpreter. When the Tcl interpreter returns, tclTest prints the return value or error message. TclTest defines a few other additional commands most notably: echo arg arg ... The "echo" command prints its arguments on standard output, separated by spaces. There is a test suite for Tcl in the subdirectory "tests". Read the README file in that directory for more information on how to use it. The file "changes" describes recent changes that have been made to Tcl. If this isn't your first Tcl release, you should probably look through "changes" to see what's changed. If the major release number has changed, i.e. from 2.x to 3.x, it means that there have been changes that aren't backward-compatible. I can't promise to provide a lot of help to people trying to use Tcl, but I am interested in hearing about bugs or suggestions for improvements. Send them to me at "ouster@sprite.berkeley.edu".
barry@pico.math.ucla.edu (Barry Merriman) (06/05/91)
In article <1651@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >There's entirely too much focus on "applications for morons," ... >which provide no feedback about what they're REALLY doing >so you don't LEARN anything, and can't fix things when they break ... >These guys haven't got a clue. When I set up machines, >I decided how *I* wanted them configured, not from what a braindead >GUI app thought was "good enough." ... You don't get that from clicking >buttons. You get that from using the lower-level tools Absolutely! And there's also too much focus on "programming for morons", which provides no feedback on what they're REALLY doing so they don't LEARN anything, and can't fix things when they break. Those programmers haven't got a clue. When I write software, I code it the way *I* want it, not the way some braindead compiler thought was "good enough". You don't get that by using "languages", You get that from using lower-level tools: coding in binary and entering your code by reconnecting the cables on the switchboard. This way when something breaks, I can see exactly which cable came loose or which tube burned out, and replace it. >The NeXT is a damn fine UNIX box, and don't you forget it. > > -=EPS=- The ENIAC is a damn fine box of vacuum tubes, and don't you forget it. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) (PS: no flame intended---just remeber, one man's low level tools are another man's high level tools :-) -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet) barry@arnold.math.ucla.edu (NeXTMail)
adonis1@nwnexus.WA.COM (Adonis Corporation ) (06/05/91)
In article <1991Jun3.050426.28427@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: >In our effort to make NeXTSTep more UNIX-userfriendly, we should >catalog our current difficulties, and see if they can't be resolved >either via some Apps, or some added functionality from NeXT. > [stuff deleted] > >(3) tar/untar a file >(4) compress/uncompress a file A shareware program called ComingOut does this. >(5) grep-ing a file Digital Librarian will search anything, indexed or not. >(6) looking/getting inside of an <Appname>.app directory, > mailboxes, and other directories that the browser can't > see inside of (I hate when that happens!) In Workspace, select the .app directory and do File.OpenAsFolder. >(9) doing ``ls -a'' to see files starting with a ``.'', > or to look in UNIX directories like /etc, etc. > (I know the UNIX Expert setting in Preferences toggles this, > but its a pain to have to use Preferences to change it) In Workspace, select the root directory and type "etc". The Find panel comes up. Press FindFile and the user directory is listed in Worlspace. > [suggested fixes deleted] Doug Kent Independent NeXT Developer adonis1@nwnexis.wa.com
scott@mcs-server.gac.edu (Scott Hess) (06/05/91)
In article <1991Jun4.215416.905@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: In article <1651@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >There's entirely too much focus on "applications for morons," ... >which provide no feedback about what they're REALLY doing >so you don't LEARN anything, and can't fix things when they break ... >These guys haven't got a clue. When I set up machines, >I decided how *I* wanted them configured, not from what a braindead >GUI app thought was "good enough." ... You don't get that from clicking >buttons. You get that from using the lower-level tools Absolutely! And there's also too much focus on "programming for morons", which provides no feedback on what they're REALLY doing so they don't LEARN anything, and can't fix things when they break. This almost isn't funny - the NeXT, as any large programming project (ie, X11, Unix, etc) has loads of places where I'd really like to go in and fix things when they break . . . but I can't because the system is "Programmer Stupid". [ When the Mac came out, the term was "User Stupid" - a novice could use most programs just as well as an expert. On the one hand, that could be blamed on the ease of use. On the other hand, an expert in Unix can beat the pants off an expert NextStep person when it comes to file manipulation and the like - because Unix gives you alot more room to grow. ] Later, -- scott hess scott@gac.edu Independent NeXT Developer Graduated GAC Undergrad! <I still speak for nobody> Note: I have moved home for a time. My email address will still be valid. Any SnailMail should be redirected, along with phone calls. At the least, my parents can tell you how to get hold of me, or forward any mail . . . Old: PO 829, GAC, St. Peter, MN 56082 (507) 933-8466 New: RR#4 Box 227 Pipestone, MN 56164 (507) 825-2788
grant@gouche (Grant J. Munsey) (06/06/91)
I have a small class that interfaces tcl to Objective C. I use tcl as a plugboard between the user interface and applications code. The class is minimal but it does allow IB generated interfaces to invoke tcl procedures via action messages and also allows tcl to send Objective C type messages. If anyone is interested I could post it to Purdue. One word of warning, I believe that NeXT, at some point, will have a much better tcl solution so I wouldn't want to claim that my stuff is anything but a novelty. ---- Grant Munsey, Mainticore, Inc. (408) 733-3838 grant@gouche.portal.com or decwrl!apple!portal!gouche!grant
rbp@investor.pgh.pa.us (Bob Peirce #305) (06/07/91)
In article <1651@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <1991Jun3.050426.28427@math.ucla.edu> > barry@pico.math.ucla.edu (Barry Merriman) writes: > >>(6) looking/getting inside of an <Appname>.app directory, >> mailboxes, and other directories that the browser can't >> see inside of (I hate when that happens!) > >Try Command-Shift-O > Doesn't clicking on "open as folder" do this? I know I've gotten into *.app directories this way. I haven't tried it on mail. I used somebody's posting along these lines to get console in my dock. -- Bob Peirce, Pittsburgh, PA rbp@investor.pgh.pa.us 412-471-5320 venetia@investor.pgh.pa.us [NeXT Mail] ...!uunet!pitt!investor!rbp [UUCP]
person@plains.NoDak.edu (Brett G Person ) (06/19/91)
Just curious about something. Is anyone using their next strictly as a UNIX box? -- Brett G. Person North Dakota State University uunet!plains!person | person@plains.bitnet | person@plains.nodak.edu