That's already valid syntax that already does something completely different.
It redirects from an open file descriptor. It's conceptually the same operation whether $fd is a numeric file descriptor or some "special file descriptor object".
Quote:
Shoehorning your solution in there will break existing code. Pick something else.
You know, I'm not placing too high a priority on backward compatibility here. If people have existing code that works with an existing shell, they can go on using that code with the shell it was written for. I wouldn't expect code written for bash to run perfectly in ksh, either. Any extensions either shell provides over baseline Bourne shell is very likely not going to work.
That said, I don't see how my idea breaks anything. It could coexist with explicitly numbered FDs as long as the mechanisms for opening the file are kept distinct.
But explicitly numbered FDs for files opened in the shell aren't really that valuable a feature anyway. If someone opens a file in the shell, they actually have no need to know the number of that file descriptor. (Assuming, as I generally do, that the shell shouldn't indiscriminately export all open file handles to every job it runs.) At most, people need to be able to know what numeric file descriptor an open file will open in a job if they want the job to have access to that FD - and even that is a fairly rare case. I'd just as soon break compatibility if it leads to a superior overall design.
Quote:
...aside from the fact that you want this to be a shell language, that is. Among other things that means weak typing.
Traditionally, it means weak typing. There's no reason a new shell would have to follow the same pattern. From my experience working with PHP I'm not a huge fan of weak typing, honestly.
Anyway, what I've described is already a form of weak typing. It's weak typing in the same sense that integer variables can only take integer values, but can be inserted into strings without explicit conversion.
The important principle of weak typing, that you can put whatever wherever and have a reasonable (but not foolproof) expectation that it'll do what you want, is preserved.
Quote:
Quote:
("If you redirect a block, you have to put the redirection at the end of the block...")
No you don't.
[edit] that doesn't work for shell builtins like while.
Well, shell builtins like while were exactly what we were discussing... What you described here isn't redirecting a block at all.
But, as you suggest - there's no apparent reason this couldn't be added to bash or similar shells... So it's not like it's something that would require revolutionary change to address the issue - unless I'm missing some subtle syntactic issue that makes it so.
Quote:
You can bodge it in with <file cat | while but that's not elegant.
It also only gets you one file... If you dup the file to another FD inside the block, the open file's lifetime is no longer tied to the scope of the block.
Quote:
Quote:
...instead of wherever it makes sense within the block... What if you've got an "if" statement that tests whether a file exists, and you want the file to be opened only if the condition is true?
Then you check if the file exists, and open it. You have all those features already. Nothing's forcing you to redirect into code blocks except that it frequently makes sense to do so
But the whole point of redirecting into code blocks (for the purposes of this discussion) was to gain scoped lifetime for open files... If it can't be used effectively then we're kind of back where we started on the whole "scoped file" issue, and it's something current shells don't usefully provide.
Quote:
Quote:
Also, the scoping mechanism appears to be broken in my installed version of bash... (4.1.5) - the file stays open. I don't know offhand if this is considered a bug.
I'd presume not. Why should {f} close just because it's on the same line? It's not like stdin closes.
If you were redirecting stdin for the block, yes that stdin would close, and you'd get your previous stdin back - even though the builtin runs in the shell's own process.
Though I guess what I described in bash is only the case if you're making a dynamic FD assignment as part of the redirection:
So I guess I was wrong there - "scoped file open" isn't broken in Bash 4, it's just incompatible with dynamically assigned file descriptors... It's an unfortunate disparity and it plays out as one more limitation of the current implementation of scoped-lifetime open files in the shell. But it's probably just a bug and not an intended behavior. And, of course, it only applies to bash...
Quote:
Writing shell code frequently means different decisions about how you lay out your code because of the way code blocks work.
But the way code blocks work can be changed. If an alternate design would make the shell a nicer environment to work in, then such change is a good thing. Programming languages evolve over time. Even shells have gained lots of new features over the years. Numeric variables, expanded substitution and history recall syntax, arrays, regexes, coprocs...
(side note, I was pleasantly surprised when I found out, just the other day, that bash 4 includes coprocs! Seems like a nice implementation, too... the FDs for communicating with the new coproc are dynamically assigned and stored into an array variable...)
Quote:
If you don't want a shell language, don't use a shell language
if you don't want to use this feature sensibly, don't use a shell language.
If you don't want that, don't use a shell.
And again, and again, and again with this crap.
Look, the fact that what I come up with doesn't fit what you're used to from a shell doesn't make it not a shell. It could be not a Posix shell, or not a Bourne-compatible shell - but "shell" doesn't mean exactly and only what the usual Unix implementations provide.
To me the defining characteristics of a shell that set it apart from other programming languages are:
1: Its primary mode of operation is to run other programs, provide them with input and do useful things with their output.
2: It's well-suited for interactive use, but the way it's used interactively also translates nicely to non-interactive use (scripting).
This is a pretty broad definition, of course, but a pretty essential one. It leaves a lot of room for different approaches to shell design - many of which wouldn't nicely fit with Unix shell tradition. I think it can be worthwhile to break from tradition - or if nothing else to consider it. Status quo shouldn't blind us to the potential offered by other possibilities. But to be clear what I want is a shell. I just see no reason for this dichotomy... It doesn't have to be "The Unix shell as it's presently implemented" or "not a shell at all".
(EDIT): Yeah, I guess I'd agree that it's probably time for this whole discussion to be extricated from this particular thread. I might go with "speculative shell features" as a title - but whatever works, really...
Hi ,
I am having one situation in which I need to run some simple unix commands after doing "chroot" command in a shell script. Which in turn creates a new shell.
So scenario is that
- I need to have one shell script which is ran as a part of crontab
- in this shell script I need to do a... (2 Replies)
Hi
I tried with bash --login option. but the output is
siva:~$ bash --login
siva:~$
is there any way to make the shell ask for user id and password ( and login as different user instead of using sudo / su )
Thx in advance
Siva (3 Replies)
i have a small problem getting a batxh shell script to run in shell
this is the code
the problem seems to be centered around the ffmpeg command, something maybe to do with the ' ' wrapping around the vhook part command
this is a strange problem , if i take the ffmpeg command and... (1 Reply)
Hi,
I am using HP-UNIX.
I have a requirement as below
I have to change env twice like:
cadenv <env>
cadenv <env>
ccm start -d /dbpath
ccm tar -xvf *.tar
ccm rcv ....
mv *.tar BACKUP
but after I do the first cadenv <env> , I am unable to execute any of the later commands .
... (6 Replies)
Hi,
I am new to unix and using linux 7.2. I would like to create a script that would make it easyer for me to run my java programms. At the moment I have to type java myJavaprogram
I am trying to write a script that will allow me to type something like this "myscript myJavaprogram" or maybe... (4 Replies)
Hello gurus,
I have three korn shell script 3.1, 3.2, 3.3. I would like to call three shell script in one shell script.
i m looking for something like this
call 3.1;
If 3.1 = "complete" then
call 3.2;
if 3.2 = ''COMPlete" then
call 3.3;
else
exit
The... (1 Reply)
basically i'm tired of hitting the left arrow a few dozen times when correcting a mistake or modifying a history command
i'd like to use vim style key shortcuts while on the command line so that a 55 moves the cursor 55 places to the left...
and i want all the other vi goodies, search of... (3 Replies)
Dear Friends,
Please help me on this
my script name is send.csh
In this i have written the statement like this
set args = ( city state country price )
I want to pass this array to another c shell called receiver.csh. and i want to use it in this c shell
or
how to pass to... (2 Replies)