[1.56][Ssp]Shell.setdir() Causes Crash

CC Version: 1.56 Client
Description: Putting

shell.setDir()

into the startup file causes a crash each time the computer starts. Although it should be treated as a normal error and continue, it does not. The error given is

shell:207:attempt to concatenate nil and string
Press any key to continue

After any key is pressed, the computer shuts off, creating an infinite loop of crashing, rendering the computer unusable.
Reproduction:
1. Spawn computer (any type)
2. Type

edit startup

3. Type

shell.setDir()

and save.
4. Reboot.

One more note: I've only tested this on SSP, but I'm going to assume that the problem persists on SMP.

Not a bug. Please check the usage for shell.setDir() and note that it requires a string argument.

Moved to Ask a Pro.

I'm not that dumb. I'm saying that passing it without an argument creates a permanent crash when put in the startup file of a computer. Unless it's a feature, not a bug? :huh:/>
EDIT: I italic'd the part where I said it renders the computer unusable, in case you missed that.

Place a disk drive next to the computer containing a disk with any empty file named "startup".

Lyqyd, on 28 August 2013 - 12:48 AM said:

Place a disk drive next to the computer containing a disk with any empty file named "startup".

While that may work once, my point is that it's not supposed to happen. Ever.

There are many, many ways to temporarily brick the computers. It's not a bug, and that's the whole reason disk drives take precedence in the boot order. You may disagree with the design decision, but that's simply the way it works.

Why not just let it return an error like everything else instead of crashing? I must be missing something here.

Because that would be extra work.

immibis, on 28 August 2013 - 04:48 AM said:

Because that would be extra work.

That's what bug fixing is.

OpieThePug, on 28 August 2013 - 11:13 AM said:

That's what bug fixing is.

Not if the bug doesn't get fixed… gotta think in the mind of a normal programmer here…. we're lazy, want to do minimum work, and prefer to not support things after we have finished them. :P/>

Not saying dan or anyone on the CC team is like this, but that is the mindset of an average professional programmer. We don't want to do more work than we need too, we already work crazy hours as it is for minimal pay :P/>

Because nobody answered your question I will:

shell.setDir() requires a string argument. It doesn't check if it is given or not when manipulating with it, so the function just errors, as well as the shell. Because it was top level shell BIOS gives you the error and waits for user input, then reboots the computer.

I hope you understand what I'm saying.

~LEGO

MKlegoman357, on 28 August 2013 - 11:50 AM said:

Because nobody answered your question I will:

I draw your attention to this:

Lyqyd, on 28 August 2013 - 12:25 AM said:

Not a bug. Please check the usage for shell.setDir() and note that it requires a string argument.

I'm pretty sure a good 50% of people see that I wrote the first reply and just ignore it, assuming all I said was, "Split into new topic." :P/>

Anyway, this comes down to the fact that some (many!) API functions in ComputerCraft use error() when they aren't fed the input or type of input that they expect. That's a perfectly valid design decision, and leaves it up to the programmer to ensure that they are providing correct input. This sort of thing is usually found in the testing phase of a program and corrected then, before it gets written in to a startup file. That's the appropriate response here, to test your code thoroughly so that your misuse of API functions will be noticed before you put it into your startup file. However, the developers, understanding that mistakes happen, give you a recovery option (the boot floppy), so that you have an opportunity to fix your startup file.

theoriginalbit, on 28 August 2013 - 11:18 AM said:

OpieThePug, on 28 August 2013 - 11:13 AM said:

That's what bug fixing is.

Not if the bug doesn't get fixed… gotta think in the mind of a normal programmer here…. we're lazy, want to do minimum work, and prefer to not support things after we have finished them. :P/>

Not saying dan or anyone on the CC team is like this, but that is the mindset of an average professional programmer. We don't want to do more work than we need too, we already work crazy hours as it is for minimal pay :P/>

I'd change it myself if I knew Java.

Lyqyd, on 28 August 2013 - 12:46 PM said:

I'm pretty sure a good 50% of people see that I wrote the first reply and just ignore it, assuming all I said was, "Split into new topic." :P/>

Anyway, this comes down to the fact that some (many!) API functions in ComputerCraft use error() when they aren't fed the input or type of input that they expect. That's a perfectly valid design decision, and leaves it up to the programmer to ensure that they are providing correct input. This sort of thing is usually found in the testing phase of a program and corrected then, before it gets written in to a startup file. That's the appropriate response here, to test your code thoroughly so that your misuse of API functions will be noticed before you put it into your startup file. However, the developers, understanding that mistakes happen, give you a recovery option (the boot floppy), so that you have an opportunity to fix your startup file.

My point is that it shouldn't reboot. It should say, "oh here's an error" instead of rebooting and causing frustration.

I think you are misunderstanding why the computer shuts down. If this code were in any other program and you started it from the shell after booting normally, it would simply print the error and end the program. However, since you put this code (clearly without testing it) in the startup file, you have given it the ability to throw the error in such a way that it ends the shell coroutine, which causes the computer to shut down. There's no bug here. There's no involvement with the Java side at all. It's purely Lua doing exactly what you told it to, which is crash in such a place that you end the shell itself. If you had instead tested the code as a separate program before putting it in your startup file, you would have found the error and corrected it.

There's no bug here, so I've no idea what you expect us to do about it. We already anticipate and protect against this sort of mistake by providing the boot disk recovery method.

theoriginalbit, on 28 August 2013 - 11:58 AM said:

MKlegoman357, on 28 August 2013 - 11:50 AM said:

Because nobody answered your question I will:

I draw your attention to this:

Lyqyd, on 28 August 2013 - 12:25 AM said:

Not a bug. Please check the usage for shell.setDir() and note that it requires a string argument.

Lyqyd, on 28 August 2013 - 12:46 PM said:

I'm pretty sure a good 50% of people see that I wrote the first reply and just ignore it, assuming all I said was, "Split into new topic." :P/>/>

-snip-

You both misunderstood me.
I can see that he understands why does it error, but I think he wanted to know why is it showing in such form. Because all other errors just stop the program and let you analyze it without rebooting the computer.

And don't worry Lyqyd, I read every post before I post something. (btw, what "Split into new topic." means? You write that a lot.)

MKlegoman357, on 28 August 2013 - 02:15 PM said:

btw, what "Split into new topic." means? You write that a lot.

New members (i.e. anyone with < 3 posts) cannot create their own threads, only post in existing threads. So this thread has been provided to them so they can get it split into it's own topic and receive help (I'm sure you've seen it before)… As such when Lyqyd states "Split into new topic" normally it means that he is splitting the comment from that thread into its own thread. Sometimes it's from other threads though when someone tries to hijack someone else's topic. I think once I saw him so used to typing it, he typed it in a thread that he hadn't actually split 'cause they posted it, funny day :P/>

theoriginalbit, on 28 August 2013 - 02:21 PM said:

-snip-

Now I remember, Thanks :)/>

Lyqyd, on 28 August 2013 - 01:27 PM said:

I think you are misunderstanding why the computer shuts down. If this code were in any other program and you started it from the shell after booting normally, it would simply print the error and end the program. However, since you put this code (clearly without testing it) in the startup file, you have given it the ability to throw the error in such a way that it ends the shell coroutine, which causes the computer to shut down. There's no bug here. There's no involvement with the Java side at all. It's purely Lua doing exactly what you told it to, which is crash in such a place that you end the shell itself. If you had instead tested the code as a separate program before putting it in your startup file, you would have found the error and corrected it.

There's no bug here, so I've no idea what you expect us to do about it. We already anticipate and protect against this sort of mistake by providing the boot disk recovery method.

Thank you for the in-depth explanation. "Not a bug" simply doesn't cut it for me.

MKlegoman357, on 28 August 2013 - 02:15 PM said:

I can see that he understands why does it error, but I think he wanted to know why is it showing in such form. Because all other errors just stop the program and let you analyze it without rebooting the computer.

This is exactly where I'm coming from.

No worries, the Ask a Pro section is here for learning! I just didn't realize at first that there was a misunderstanding of that sort that remained to be cleared up after my initial posts.