It is, repeat is and does, have scripting support.

I am releasing the first version of LinuxOS (version 3.0) with BIOS version 5.0. The program will really benefit as soon as a dim(84 bug is released, and Filesyst gets restructured. Once that happens, I am going to rebuild most of the commands for use in a filesystem format. For example, the password files will actually be in /etc/shadow, instead of in an appvar. While I highly doubt that this program will crash your calculator resulting in a RAM clear, (if it does, tell me exactly what you ran) I cannot fully guarantee that it won't. As of yet, I have not had this program crash my calculator since it got out of the very beginning stages, and I consider it quite stable. A full list of all the programs can be done by executing this command
dim64,"U/bin","EPROGS
In the program PROGS, you will now see all the files and programs currently installed. You should be able to add more with the install command though I can't remember if it's bugged or not. The program cat is currently bugged unfortunately, or better said, the fileRW is, so neither "cat" nor "more" currently work. Running "more" will give you a syntax error and running "cat" will run the login command. If you're curious on seeing how the programs are constructed, it's not hard. Just type in dim(21,"U. plus the program name. So, for example, to see how the program "more" is constructed, run dim(21,"U.more

Speaking of which, you should learn some BatLib commands while you're at it, so you totally understand how the program works.


As for now, here is the program:
Mirror 1:
http://ubuntuone.com/3cS2sB35pVlBDgIDx6fq11

Mirror 2 (in case the first one doesn't work)
https://www.dropbox.com/s/wpfr47ql6h5wv7k/LINUXOS.8Xo

Keep in mind that this requires the very newest version of BatLib, released just a day ago. To download it:
http://www.omnimaga.org/index.php?action=dlattach;topic=5383.0;attach=14502

Do you have any screenshots for this? I see you've decided to continue calling your shell LinuxOS. Will it warn you if Grammer is not present on your calculator? What are some of the major features?

Grammer is not actually used. I do have screenshots, which I'll post later. I've continued calling it Linux based off of it's just easier to remember but I concede the fact that it isn't really

I don't know if you have incorporated FileSyst in yet, since it is basically stable now. Is there anything that I should add to it to help this project?

Actually no, I hvven't incorporated FileSyst yet, mainly because I'm a lazy bum who's been busy trying to optimize the Programs >< It's definitely on my to-do list, and I'm certain that once I get around to start the incoporation, functions I need will come up. As of now, I don't really think there is anything. I'll give you the code for all the programs for your perusal, there's probably some BatLib command I used somewhere that I forgot to ask for inclusion.

Oh, okay. I was thinking that it could work with FileSyst in its current state or BatLib (interchangeably), but I wasn't sure about that. If I can add the command to populate a folder with a certain OS variable type, I will. It would make it a lot easier than the current method we have. I don't remember if I released the version with the new command for searching the VAT, but I know I found some glitch that I have been trying to weed out (with unrelated code).

Yes, I've been running into a certain glitch myself, which happens with the pop-up menu and has no reasonable explanation...nothing in the code should be causing it to happen. And it only happens sometimes and fixes itself as soon as I add a colon to the command after it. Then, it'll come back, and as soon as I delete the colon it goes away again. It's really odd. I think BatLib may be screwing up some RAM addresses every now and then too. Sometimes, Linux will glitch up oddly for no apparent reason. Never crashed the calc, but gotten some weird things happening.

Hmm, that does sound like a bit of a problem. I don't think there is any code in the PopUp routine that can cause such a problem. It is probably some other routine causing a glitch like that. It isn't easily reproduced, is it?

No, not at all, none of these bugs are. I had one in which dim(67,{42, which should be returning the quote ( " ) was instead returning the letter N. I couldn't reproduce it anywhere outside the program! I eventually fixed the problem by using dim(65,42 which has yet to glitch out on me. You actually have the code to the program, (it's somewhere on TiBD) but here's the lines of code that seem most likely to be affecting it:


Code:

Hmm, actually, I think I might know what is going wrong here. I may or may not have caught it yet because another command had a similar bug at one point. dim(67 is one of the few commands that directly edits the passed data. Most commands create a new var to return data. If this is indeed the problem, the fix should be 4 bytes resetting a certain flag (I forgot the name of it).

Ah, I see. Well, the point is moot now anyway, considering that dim(65,42 is smaller than dim(67,{42 Any idea about the other one? It just seems to go in and out.

Oh wait I haven't even told you what it does ><

So normally, there are three options in the boot menu (two without Linux installed) but sometimes it shows six instead. The last three are repeats of the other ones so the options go Linux, TI-OS, Shutdown, Linux, TI-OS, Shutdown.

ooh, that is really weird. Are you able to move the cursor to those other options?

Yes, and clicking on them generates the correct Ans value for those options too. It's almost like it's somehow just replicating the string/options.

I'm going to start incorporating filesyst here soon... It's something that I've been holding off on and just debugging and optimizing but I think that I'm about as far forward on that as I'm going to get. It's time to start actually writing some new code.

Hopefully this will add a new level of awesomeness I have some ideas for things to add to FileSyst that should be useful, including an easier way to handle custom file extensions. I was thinking that extensions not recognised by FileSyst would simply look for an appvar with a certain name (probably like 0EXTtmap for .tmap) and the code could be Assembly or BASIC and it would have certain arguments passed, accordingly. Then the program could handle the file as needed. It would allow users to easily install programs to handle special file types, and it would be easier to handle filetypes.

I would be stoked about that So in a way, when it comes across a filetype it doesn't recognize, you could search through a program's "metadata" searching for its ability to open that filetype. To do that, it would be best to use one of those comment fields for files in Filesyst, and then have it load all appVars as files. If the code is runnable, mark it as executable. Ah, you know what, I'll implement that particular trick from within Linux. On the other hand, I do need to know where it's loading the pointers to. If you could just make it so that when you find the variables you just put pointers in the current working directory, that would probably be best. I'll take care of moving them to their necessary positions for Linux to make use of. Also, is the var that actually holds the Fileystem archived? Or is it archivable without losing everything? It's not a big deal if it isn't, in fact, it would be totally fine, almost preferable, but I'm just curious. Out of curiosity, what is the root directory of Filesyst? In Linux, it's "/", in Windows i's "C:", what is it in Filesyst? Can you make multiple "partitions" or Fileystems? That would be cool

Right now, the file system is stored in RAM without the ability to archive it. However, my plan is to allow FileSyst to read Groups as a type of folder and hopefully I will give it a way to recognise archived folders. The way I typically handle going back to the root directory is to enter a directory that is in the root directory, then use CD(..) As an example:

Code:

Heh, I would suggest changing that if possible...just make the home directory "/"...that would make coding Linux significantly easier!

A hopefully long awaited update on this still rolling project:

I added in a better, more robust and modifiable boot system that works by executing commands out of a seperate file. This file can be Linux commands are TI-BASIC (along with a certain header). I made the terminal an actually separate program like how it is in actual Linux, so that now, one is capable of say, installing a GUI and that program can directly modify the boot sequence to point to the GUI instead of just a shell. Right now, this is the extent of the boot file:

bash
That's just a Linux command that executes the command "bash", which is a terminal. But you can modify that file however you want (you just need to generate a hash so that Linux can verify the boot image when it starts up). This makes Linux a lot more dynamic, and adding GUI's should be A LOT easier now! Now, you can code whatever GUI you want that can interface with the Linux commands, plus it stands as, in my opinion, a great skeleton system for coding entirely different OS's altogether, on top of Linux. ACagliano may also be helping me make this project a reality in the near future. I hope that he will help me port the originally BatLib program to the Filesyst parser hook andI hope to hear that people are still interested in this project, cause I'm planning to make the final push to a full, actually working, actually useful, Linux-like OS!