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

Reduce dependency on system commands #17

Open
robsimmons opened this issue Nov 19, 2011 · 3 comments
Open

Reduce dependency on system commands #17

robsimmons opened this issue Nov 19, 2011 · 3 comments

Comments

@robsimmons
Copy link
Member

magenbluten writes in comments to #15

as i already mentioned "rm -Rf" doesn't work on windows systems. aditionally the "FSUtil.systemLines" uses "someprog > somefile" for capturing and parsing program output. this of course does also not work on windows systems and should be fixed. i think of writing a "shell-monad" similar to "hsh (haskell shell)" for similar tasks.

rm -Rf is indeed one of the couple of things that necessitate running smackage within the cygwin environment in Windows, and it would be better to create a SML-level facility for crawling the directories, deleting stuff and then deleting the directories.

I believe our testing was that pipe-to-file works in the Windows cmd shell - can we get a confirmation that pipe-to-file does not work using OS.Process.system in Windows XP/Vista/7? I was under the impression that it did.

If that doesn't work, I don't know of a good alternative, since "fork" only exists in Posix.

@gian
Copy link
Member

gian commented Nov 19, 2011

Isn't there a windows recursive delete command? Isn't it called 'deltree' or somesuch?

@robsimmons
Copy link
Member Author

True enough, Windows usually has its own commands to do stuff, they're just different.

Since we already have a separate compilation path for Windows, I wouldn't be sad about having an "fsutil-windows.sml" that duplicated "fsutil.sml". Fundamentally, though, I'm going to think of cygwin support as good enough unless we get someone who is interested in poking around and testing things in Windows.

@gian
Copy link
Member

gian commented Nov 19, 2011

I heartily agree at this point. Non-cygwin windows support would be lovely and all that, but I'm not sure it's high priority just yet.

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

No branches or pull requests

2 participants