earl@motcid.UUCP (Brent R. Earl) (03/26/91)
I believe that I am working with SKsh v1.40 (?). I am having trouble setting some of the SKsh environment variables. I have tried HOME=app: and end up with HOME=: (which is the default). What am I doing wrong? I can successfully assign other non-environment variables, just have problems with these startup ones. Reply to uunet!motcid!earl (why trust the evil mailer?)
rmr@ccwf.cc.utexas.edu (Randy M. Roberts) (03/27/91)
In article <6765@khaki14.UUCP> motcid!earl@uunet.uu.NET (Brent R. Earl) writes: |I believe that I am working with SKsh v1.40 (?). I am having trouble |setting some of the SKsh environment variables. I have tried HOME=app: |and end up with HOME=: (which is the default). | |What am I doing wrong? I can successfully assign other non-environment |variables, just have problems with these startup ones. | |Reply to uunet!motcid!earl (why trust the evil mailer?) I know you'd rather me reply to you by email, instead of posting, but I'm lazy and hit the F key instead of the R key, and ... well ... here I am. Did you "export" the variable after you set it? $ HOME=app: $ export HOME Try this, it should (hopefully) work. You really should get SKSH1.6 from "the alphabet" ftp site (you know abcfd20.larc.nasa.gov :-) request: I hope they add all the neat variable modifier syntax that KSH has! Regards, Randy -- Randy M. Roberts rmr@ccwf.cc.utexas.edu
robtu@itx.isc.com (Rob Tulloh) (03/28/91)
rmr@ccwf.cc.utexas.edu (Randy M. Roberts) writes: >request: >I hope they add all the neat variable modifier syntax that KSH has! Let's here it for this request! And could I also request redirection syntax so that I can do things like: prog 2>&1 | more This would be a tremendous plus! >Regards, >Randy >-- >Randy M. Roberts >rmr@ccwf.cc.utexas.edu -- INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116 9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!) Arboretum Plaza One, Suite 700 Net: robertt@isc.com (polled daily) Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)
koren@hpfcdc.HP.COM (Steve Koren) (03/30/91)
> |What am I doing wrong? I can successfully assign other non-environment > |variables, just have problems with these startup ones. Are you typing this in from the keyboard, putting it in your .skshrc, or what? This works fine in 1.6, so I recommend you upgrade: [ram:]: echo $HOME SYS: [ram:]: HOME=ram: [ram:]: echo $HOME ram: [ram:]: version -d 16:44:24 Oct 4 1990 [ram:]: It should have worked fine in 1.4 too, which leads me to wonder wherther, perhaps you have put this in your .skshrc and not assigned sksh: do that directory, so SKsh doesn't see the file? Or perhaps you have a .skshrc.pp file there which is being executed instead. Another potential reason is if you execute (not source) a file which sets HOME, but you don't export HOME afterwords. The new variable definition will be lost when the script exits. > request: > I hope they add all the neat variable modifier syntax that KSH has! By "variable modifier" syntax, do you mean all those ${foo:bar} style things? "They" (ie, "I") have been considering adding those, but no one asked, so I never did... The best way to get requests implemented is to mail them directly to me. It is purely be coincidence that I happen to catch things about SKsh posted to comp.sys.amiga.*. - steve
koren@hpfcdc.HP.COM (Steve Koren) (03/31/91)
> Let's here it for this request! And could I also request redirection > syntax so that I can do things like: > prog 2>&1 | more Redirection syntax already is in there (ie, try "command > file"), but the case you point out above is something slightly different. It directects stuff sent to stderr (file descriptor 2) to go to stdout. The Amiga doesn't really differentiate stderr and stdout - programs have just one place to dump output to, unless they open up another output themselves. Since 99% of all programs don't make a distinction between stderr and stdout, SKsh doesn't support assigning one to the other. There is also a limitation on where redirection symbols can come in a line: at the beginning or end only. Thus, you can say: cmd1 | cmd2 > output but not: cmd1 > output | cmd2 which is logically the same thing but slightly more confusing. There is another difficulty in piping things to more on the Amiga. Some "more" commands will, if they detect that stdin is not a console, open up the console themselves. These more commands can be piped to. Most, however, won't check, and so you can't pipe stuff into them. You have to find an applicable more command before you can use it with pipes. - steve
robtu@itx.isc.com (Rob Tulloh) (04/05/91)
koren@hpfcdc.HP.COM (Steve Koren) writes: First, let me refer back one post to the variable substitution request. I, for one, would love to see this in sksh as it one of the big advantages of using ksh over other shells which force the used of basename, dirname, and sed to accomplish simple substitutions/deletes. So if asking helps.. >> Let's here it for this request! And could I also request redirection >> syntax so that I can do things like: >> prog 2>&1 | more >Redirection syntax already is in there (ie, try "command > file"), >but the case you point out above is something slightly different. >It directects stuff sent to stderr (file descriptor 2) to go to stdout. >The Amiga doesn't really differentiate stderr and stdout - programs >have just one place to dump output to, unless they open up another >output themselves. I had been wondering about this. I couldn't decide if the Amiga had a notion of file descriptors or not since the native CLI only lets you do things like < and >. >Since 99% of all programs don't make a distinction >between stderr and stdout, SKsh doesn't support assigning one to >the other. There is also a limitation on where redirection symbols >can come in a line: at the beginning or end only. Thus, you can >say: > cmd1 | cmd2 > output >but not: > cmd1 > output | cmd2 >which is logically the same thing but slightly more confusing. >There is another difficulty in piping things to more on the Amiga. >Some "more" commands will, if they detect that stdin is not a console, >open up the console themselves. These more commands can be piped >to. Most, however, won't check, and so you can't pipe stuff into >them. You have to find an applicable more command before you can >use it with pipes. I take it that released version of more (the one that shipped with the machine) does the open the way you say some programs do? I cannot explain why my progs which write to stderr don't interface to more the way I want them to. I would be suspicious of less since it goes to the trouble of opening its own window, but how about native more? > - steve Another question, is there a limit to the number of filenames that sksh shipped grep will accept on its command line? I wasn't aware of a limit on the command line length. A simple test of echo seemed to indicate it was capable of handling a lot of arguments (echo * */* on a rather large directory with lots of subdirectories). Is there a limit that grep imposes? Thanks for the feedback on these items. I find it very useful. Rob Tulloh -- INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116 9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!) Arboretum Plaza One, Suite 700 Net: robertt@isc.com (polled daily) Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)