Hi! Ralph Glasstetter wrote:
>>Checking the exit status with wait/waitpid is a little tricky. You need >>to evaluate the `status' argument to find out what happened. But I can >>add that myself. > > > OK, that twould be nice... > But AFAIR status didn't change in that case...!?! Au contraire. The variable reflects the reason why the program exited, plus the exit code (or signal number in case it was killed). >>>So the 'which'-version is working for me, but maybe neither "universal" >>>nor "elegant" ... the QFileInfo-Version is better concerning this but not >>>making use of $PATH, so one has to specify the full path for the pipe >>>commands... >> >>Nah, that's not so good in my opinion. You should be able to use the >>same command that you would type at your shell prompt. > > > FullACK, that was the reason why I implemented the 'which'-check, but maybe > that's no more necessary if you're checking the status now... ;-) We'll see. [...] >>>But we need a -format switch to select the output type... guess that >>>fit's into my above mentioned CLI-patch! ;-) >> >>Okay... but that should not change the current settings. > > > You mean not changing the settings().export_format variable? Precisely. > But currently settings().export_format is is used also in CLI mode as > default!!! That would mean GUI mode can change the default format used by the > CLI but not vice versa? Theoretically, CLI mode should never change any settings. Not even the list of recent files. Whether CLI mode should default to GUI mode settings is another question. > I think it's better the CLI always uses 0 as default, changable now by -format > (but not written to the settings)! OK? > Would be no good if the behavoir of CLI without -format dependens on > the type of previous GUI runs! I agree. >>>But we could also have something like: >>> >>>recentfiles/0/0=/tmp/topf/test.rec_01 >>>recentfiles/0/1=/tmp/topf/test.rec_02 >>>recentfiles/0/idx=/tmp/topf/test.rec.idx >>> >>>and break with the current format! >> >>I think that would be the best way to do it. By the way: You should also >>add the name of the bookmark (*.app?) file if there is one. > > > You mean *.add? Err, right. > Hmmm, ... at the moment there is no way to specify one (no dialog like for > the > index, where we need a default value and where it can be changed)! > Its name is determined from the first input file (in tsfile.cpp) which also > works if opening happens via recentfiles... Okay, then a separate entry isn't strictly necessary. > Maybe we can add such an dialog & recentfiles entry later if there are more > receivers using such a file...? Once it becomes necessary to specify the filename :-) > The attached patch now contains also backward compatibility for the > old recent file format, old entries will be automatically converted to new > format on output. > > The CLI now understands a -format switch (normal muxers: 0-3, but of course > also pipe formats are possible, with 4 doing the default dvdauthor > titleset+postprocessing) and the specified input files can alternatively also > stand in front of the options since all argument parsing is now done in the > beginning of main.cpp. I'll look at it more closely at the weekend. > PS: Sorry for the overlapping patches... No problem, I usually manage to get them applied anyway. You get used to the procedure in 15 years ;-) -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
