Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

filename parser bug #43

Open
sub205 opened this issue Jan 24, 2019 · 7 comments
Open

filename parser bug #43

sub205 opened this issue Jan 24, 2019 · 7 comments

Comments

@sub205
Copy link
Contributor

sub205 commented Jan 24, 2019

I noticed a strange behaviour of the filenameparser.

Examples:

[C:] copy a:TASK -> 0 files copied (wrong)
[C:] copy a:addtask* -> 0 files copied (wrong)
[C:] copy a:. -> everything fine (expected!)

[C:] dir addt* -> returns addtask.com (expected!)
[C:] dir *1238912 -> returns whole directory (wrong)
[C:] dir task -> returns whole directory (wrong)

@ghost
Copy link

ghost commented Jan 24, 2019

TSL did not try to make PC-MOS command processor 100% compatible with MS-DOS. Their selling point was multi user over termnals connected via serial cables and/or modems. Their command processor was " good enough" to run batch files crafted to be compatible.

If you want a 100% clone of MS-DOS, you will not be happy with PC-MOS.

We have the source code, and of course it can be improved, but kernel work is more important right now.

@sub205
Copy link
Contributor Author

sub205 commented Jan 24, 2019

I don't want to fix it now or get 100% DOS compatibility. It was one of the first things i noticed because i was searching for any tools with TASK in the filename for obvious reasons.

I think it's a basic in every OS but yes - it does not require immediate action. Maybe there's a whole complex of filehandling issues (see: y2012 bug) that are somehow linked together and need to be refactured at some time.

EDIT: It is important to fix this someday, imagine you are doing DEL *TEST.BAK and your command interpreter deletes everything.

@roelandjansen
Copy link
Owner

let's leave it open right now on the list. I agree that it should be fixed one day.

My initial idea is that I just think of and is open for discussion obviously..

  • kernel
  • ccp (console command processing)
  • multiuser/tasking tools
  • others
  • additional wishes.

@ghost
Copy link

ghost commented Jan 26, 2019

I support that priority order

@the-grue
Copy link
Collaborator

EDIT: It is important to fix this someday, imagine you are doing DEL *TEST.BAK and your command interpreter deletes everything.

Would it delete everything or only *.BAK?

This specific behavior of MOS is documented in the manual, section 3 "Files & Directories" page 3-5/3-6 under the "Wildcard characters" section. Specifically on page 3-6 where it gives the example:

a*c.xyz is not a legal filename. The "c" is ignored.

Specific to the word "TASK" in your examples above, are you using the word "TASK"? If so, that may be a reserved word. If not, can you elaborate what "TASK" expands to?

@sub205
Copy link
Contributor Author

sub205 commented Feb 11, 2019

At least in v5.01 (from the images i uploaded) it seems to work correctly.

I don't remember which images i used back then, i'll test and try to find.
Anyway, in our recent 5.01 it isn't repeatable, even without updat501.sys.

@the-grue
Copy link
Collaborator

Ok, I was quoting from the v4 manuals I uploaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants