- Run praat from command line install#
- Run praat from command line software#
- Run praat from command line mac#
This is something to learn from for me: namely, that it is better to continue with defensive programming, i.e. In that case, we would not have relied on undocumented behavior of operating systems (does a double-clicked process have a parent? some Windowses say yes, some say no does isatty always give us what we want? perhaps not). The real solution would have been to go with my original plan and require -run in 6.0.
Run praat from command line software#
As for your version checking, you could just prevent people from using 6.0, 6.0.01 or 6.0.02, if that is indeed the degree of detail with which you create your software (and that I have advised against). Whether 6.0.03 is relatively bug-free can only be established by having it around for weeks. That 6.0.03 is better in several respects than 6.0, 6.0.01 and 6.0.02 is no coincidence. Praat is a living program, and almost every version is better than the previous. For the SCITE case, this is actually OK, because praatcon just has to be replaced with praat -run as for prove, I don't yet know.Īnd we're not in a corner. I spoke before about the foreseeable problem with -version, and spoke before about my doubts about the reliability of command line detection. There will always be bugs that require thousands of downloads and users to be found, and those bugs therefore tend to come out at advertised releases, not before. Any ideas are welcome.ĭistributing beta versions is not a general solution. I've been trying to find ways to disable the GUI for Praat, to force it to crash if it attempts to open the GUI, but this will likely have to be platform dependent, and I haven't found a way to do it yet.
But (at least from Perl) Praat 6.0.03 will open the script for editing instead of running it unless -run is used, and this option will cause versions <= 6.0.02 to crash, also requiring user input.
This will work for all versions of Praat, as long as it is executed. So not only is it disconcerting for users, but it also makes it impossible to use this programmatically, since Praat requires user input.Īlternatively, we could run a script that said printline praatVersion. This can be wrapped in a try block, so it shouldn't be that problematic, but Praat crashes after starting the GUI. But -version will cause earlier versions (at least 5.4.22) to crash. I've been trying to write something so that can safely detect what version of Praat is running, and I don't think it can be done, at least not from Perl.įor versions >=6.0 we have -version, which makes things easier. The closest I've got is this, but it'll require some more spelunking. I've been trying (unsuccessfully) to figure out how prove calls the command passed with -exec. The problem here is that Praat thinks that, when run by prove, it should start the GUI, which is not the case (I used the "bug" label because I still think this is a bug in the tty detection). is this really "undocumented behavior"? I mean, prove is supposed to work by passing the test to an interpreter and parsing the stream of results, and praat is supposed to execute a script that is passed as an argument (from a terminal) and output to STDOUT. Why isn't there a label for "a change in undocumented behavior" other than "bug"? )īut more seriously. Prove -exec "bash praat" complains that it "cannot execute binary file", which is the same error I get if I just try bash praat. Prove -exec "praat -" just holds there, I imagine waiting for input that never comes.
Run praat from command line mac#
I guess this should be fixed by improving the detection of the environment under which Praat is called, but in the meantime it could be fixed by implementing an -exec or -run option in Praat itself (as once planned) to force execution mode (bypassing the detection altogether).īTW: This was using Praat 6.0 under Kubuntu 14.04, with Perl 5.22 and TAP::Harness 3.35Īctually, I haven't tried it on Mac or on Windows, I only know that it does not work on Linux (testers welcome!). It is probably related to the way in which prove calls Praat internally. The problem is not related to the extensions of the individual test scripts (in this case, t). Instead, each test script is read and opened in the Praat editor in turn.
t/*.t) through praat, and should result in the output of each of the scripts being parsed by prove for general statistics. The last command runs the tests (which by default match. # but prove should come with the standard Perl distribution
Run praat from command line install#
# cpanm Test::Harness or sudo apt-get install libtest-harness-perl
0 kommentar(er)
