I recently released a software to our customer, it will be installed on one machine at one location and maybe later at two other locations. It is a prototype and has to be tested.
This is a compiled Matlab GUI which runs scanning, does some image analysis and produces report. All is fine here. But I've got a complaint that batch-file I use is a thing from past DOS times, should not be used and looks unprofessional... Currently, the user should set up one path in batch file before the first use and then always run batch file. This bat-file kills some processes to avoid conflicts, including any running instances of the GUI, sets the path for results and runs the GUI. I proposed them to create a shortcut to this bat-file with a nice logo (such that they don't see the .bat extension ;)), but they are still unhappy.
What to do is probably not the main question here - client is always right and I should remove .bat somehow to make them happy. But is it really so unprofessional to release technical, not mass software using bat-files? Or is it just one person's opinion?
Personally I think if you already have a GUI, then use that to do the pre-processing. There is nothing wrong with using batch files, but using one when you have a GUI doesn't seem like the best way to do it.
Alternatively create a GUI with the same look as the main program to ask the user for the details it needs. For me it's not about professionalism, but how easy it is for the user to do what they need to do.
I see nothing wrong with using a batch file for small projects (especially during the testing phase if that is easier for you and delivers something to the client quicker). However, depending on the size of the project, it is nice to have an EXE to deliver to the client with a proper icon and what not.
I would agree with the customer that an EXE looks more professional. Whether it is or not... I'm not sure. The .bat files just seem a little slapped together whether that is true or not.
I would say this is similar to when people call PHP programs scripts because a lot of the times they are simple scirpts. But, then there are frameworks out there like Cake and Kohanna that are more than what someone would typically classify as a script but, since it's PHP there is still that connotation.
A batch file is not unprofessional. The batch "language" has disadvantages and outright problems (error handling!!) but it gets the job done and that's the point.
The problem is that it shows the internals of the program and some people are scared by this. They don't want to see anything like this and so try to find a disapproving label. The quickest solution is to hide the batch file behind a "vanity cover", or in this case an exe that hides the working from terrified eyes.
One simple possibility is to use an self-extracting zip file eg: http://www.7zsfx.info/en/
Related
I'm trying to get some automator script going but I have no clue how to achieve it. It's like this:
in Processing I exported a batch of 1850 SVG's. These SVG's now have to be opened in an application called Cenon. This application can save SVG's as .hpgl files.
It's no problem to open a file in a specific application like Cenon when it's added to a folder. That works fine.
But how do I save this file in a specific extension like .hpgl and create a variable name? Because Cenon always opens a file with the name 'UNTITLED'.
So I need to do:
automatically open file one by one in Cenon
save file as .hpgl file
save file with variable name like (0001, 0002, 0003, 0004, 0005, etc.)
I hope someone can help me!!
Thanks in advance,
Fons.
First of all, let me make a distinction between two related technologies:
AppleEvents which are messages that can be used for different applications to communicate with each other, asking each other to do tasks.
AppleScript which is one kind of scripting language that can send and receive AppleEvents to and from Mac applications.
You can't use AppleEvents with Cenon but you still may be able to use AppleScript with Cenon. I know that you can't use AppleEvents with Cenon because I downloaded Cenon version 4.0.1 from the web and I tried to open up it's AppleEvent dictionary with the "AppleScript Editor.app" application that comes with OS X.
So, AppleEvents are out. This means the "tell" command in AppleScript can't tell the Cenon.app to do anything with AppleEvents, but you may still be able to use AppleScript.
AppleScript can be used by simulating user menu-selections and key strokes instead of using AppleEvents. Using AppleEvents would be better, but sometimes, using AppleScript, you have to go through the user interface.
An alternative to resorting to using AppleScript to simulate the user-interface (UI) would be to use a shell-command. It just seems to me that this would be a better solution, but you would have to find a Unix shell command that was compiled for Mac that would convert from .svg to .hpgl
If you really want to use AppleScript and Cenon.app, here is a link to study about using AppleScript going through the UI of an app:
http://www.macosxautomation.com/applescript/uiscripting/
AppleScript was originally designed to be a scripting language to take some of the functionality with application A, and then take some of the functionality of application B, etc, and glue it together with a little logic from AppleScript and empower the user to more easily automate their tasks.
AppleScript was designed to be an alternate user-interface, going through AppleEvents, but AppleEvents are not as widely supported as they could be by applications, so this kludgy solution of having AppleScript go through the GUI is commonly done.
Again, I think that a shell script would be a better solution for this problem and you could call is "solution.command" or you could embed the shell script into an Automator Workflow saved as an Application or embed the shell script within an AppleScript saved as an application. Either one work work.
I make a fair amount portable Apps for personal use and they work perfectly for the most part. I do, however, find it quite frustrating that if I run them on another computer none of my preferences are retained, as a program always looks in appData for the configuration files (which obviously don't exist on another system), so I'm wondering whether there is some kind of command line to launch an .exe with a custom .ini location.
I'm asking this firstly because Google has proved fruitless (once again) and secondly because I know it's possible - I've actually done this before, but with only one of my Apps. I accomplished this by launching the App via the command programFile.exe -f configFile.ini /s (I have also seen programFile.exe -d -f configFile.ini /s elsewhere). Naturally, I thought I would try to apply this to some other Apps but it seems it only works for that particular App.
So, is there a command/switch that I am unaware of that will do this for an .exe file?
Thanks
It really depends on each executable file you are using. Some have support for what you are looking for, and some don't. Some programs don't even use .ini files. What you should look for is if each and every program you use have support for user data custom location.
Edit
The only case where generic arguments would be avaialble for a group of EXE files is if they are generated with the same tool, which automatically provides these arguments for you. InstallShield and MSI install programs have that kind of feature (with the silent install and automated installation for instance).
I suggest you look into the tool you are using to generate your portable Apps, and see if it does provide those generic arguments for you, and how they work. If it does not have that feature, then look into the Apps you were able to specify a custom location for your INI file. Somewhere into the code, there must be a piece of code that handles the arguments you specify to the EXE file and handles them. You should share that piece of code with your other Apps, to make sure they provide the same arguments list.
[the following is a rephrase of my previous question, which was deemed ambiguous].
I'm digging into creating a basic licensing mechanism for a demo application. What I have in mind goes like that: the application creates an empty "license file" called, say "0b1xa487x.ini" upon the first run, then expires 30 days after it has been first executed and can't be run anymore as long as that specific file is present on the system.
What I'm looking for is a method to protect that specific file in a way to deter deletion. Since it will be a blank file, devoid of any content, I wouldn't mind it to be corrupt, have corrupt headers, invalid date, whatever it takes to stay undeletable.
I've seen a similar approach somewhere based on file attributes (the file had the HX attributes set in place); however, the attribute approach lead me nowhere, as I can't find any documented feature on the existence of a file attribute X.
I also know that there are other approaches including rootkit drivers and system services launched as system user, but this particular one seems to fit best in this scenario. Again, I outline that the file's contents may as well be inaccessible, I'm not planning to use the approach in running any kind of malware from the file, as I've been accused below :)
Corrupt suggests not conforming to some standard. There are no standards for blank files.
Thanks everybody for your suggestions. I found a way to render my file inaccessible, namely by using fortunate combination of file permissions. The downside is that these things don't work on non-NTFS partitions. The good thing is that I can always clean up after my application by simply removing these permissions programatically and deleting everything afterwards.
Regarding your last answer to Henk, I believe it is more easier to create a service, start it automatically with the OS, and open the file in the fmShareExclusive by using a TFileStream.
But, you can not force the kernel of the OS, or an antivirus to make your file 'undeletable'.
Best regards,
Radu
Which configuration management tool is the best for FPGA designs, specifically Xilinx FPGA's programmed with VHDL and C for the embedded (microblaze) software?
There isn't a "best", but configuration control solutions that work for software will be OK for FPGAs - the flow is very similar. I use Subversion at work and git at home, and wrote a little on 'why' at my blog.
In other answers, binary files keep getting mentioned - the only binary files I deal with are compilation products (equivalent to software object and executables), so I don't keep them in the version control repository, I keep a zipfile for each release/tag that I create with all the important (and irritatingly slow to reproduce) ones in.
I don't think it much matters what revision control tool you use -- anything that you would consider good in general will probably be OK here. I personally use Git for a sizable Verilog + software project, and I'm quite happy with it.
What will bite you in the ass -- no matter what version control you use -- is this: The Xilinx tools don't generally respect a clean division between "input" and "output" or between (human edited) "source" and (opaque) "binary." Many of the tools like to store some state information, like a last-run time or a hash value, in their "input" files meaning that you'll get lots of false changes. Coregen does this to its .xco files, and project navigator (the main GUI) does this to its .xise files. Also, both tools have a habit of inserting or removing lines for default-valued parameters, seemingly at random.
The biggest issue I've encountered is the work-flow with Coregen: In many cases, at least one of the following is true:
You have to manually edit the HDL files produced by Coregen.
The parameters that went into Coregen are stored somewhere other than the .xco file (usually in what looks like an output file).
You have to copy-and-paste the output from Coregen into your top-level design.
This means that there is no single logical source/master location for your input to the core-generating process. So even if you have the .xco file under version control, there's no expectation that the design you're running corresponds to it. If you re-generate "the same" core from its nominal inputs, you probably won't get the right outputs. And don't even think about merging.
I suggest CM tools that support version labeling and binary files. Most Software CM applications are fine with ASCII text files. They may just store a "difference" file rather than the entire file for updates.
My recommendations: PVCS, ClearCase and Subversion. DO NOT USE Microsoft SourceSafe. I don't like it because it only supports one label per revision.
I've seen Perforce and Subversion used in a couple of FPGA-intensive companies.
We use Perforce, and its great. You can have your code that lives in Linux-land checked in side-by-side with your Specs and Docs that live in Windows-land. And you get branching, labels, etc.
I've seen everything from Clearcase to RCS used, and it is really all okay for this kind of thing. The important thing is to get a good set of check-in policies established for your group, and make sure they stick to it.
And have automated nightly regressions. That way, when someone breaks the rules, they can be identified and publicly shamed.
I have personally used Perforce, Subverion, git and ClearCase for FPGA projects. Since VHDL and C are just text files, any works fine. However be sure to capture the other project and contraint files and any libraries you use.
Also think about what to do with the outputs, e.g. log file and bitstreams. Both tend to be big and the bitstreams are binaries.
Previously I used Subversion but have switched to git two years ago. Git handles FPGA design files just as well as it handles every other text and binary file. Git is all you need for version controlling your files and artifacts.
For building the designs, I recommend just using a single ISE project called "ise" (living in a subdirectory called "ise/"). You can take a look at my (very modest) FPGA open-source project on github for the file layout. I don't bother storing the ISE files at all since they are easy to regenerate. The only things I save are the Verilog files and some ISIM waveform config files. In other projects that use coregen I save the coregen.cgp project file and all of the *.xco scripts for regenerating cores. Then I use a Makefile for actually running coregen on the *.xco files. There are a few other Xilinx-specific files you should version control too: *.ucf, *.coe, *.xcf, etc.
I experimented with using Makefiles and the Xilinx command-line tools but found that ISE did a much better job tracking dependencies and calling the tools with the right arguments. Just don't make the mistake of trying to version control your ise/ project files or you will go mad. Xilinx has something like 300 different file types which change every release. If you want to save a file, you can try the ISE project file itself with a .xise extension. Anything that is hard to recreate, like the golden bitfile that you know works and took 6 hours to build, you might want to copy that and configuration manage it explicitly.
I am writing a terminal-based application, but I want the user to be able to edit certain text data in a separate editor. For example, if the user chooses to edit the list of current usernames, the list should open as a text file in the user's favorite editor (vim, gedit, etc.). This will probably be an environment variable such as $MYAPPEDITOR. This is similar to the way commit messages work in svn.
Is the best way to do this to create a temporary file in /tmp, and read it in when the editor process is terminated? Or is there a better way to approach this problem?
There's already a $EDITOR variable, which is extremely standard and I have seen it working on a wide variety of unixes. Also, vi is always an option on any flavor of unix.
Debian has a sensible-editor command that invokes $EDITOR if it can, or falls back to some standard ones otherwise. Freedesktop.org has an xdg-open command that will detect which desktop environment is running and open the file with the associated application. As far as I know, sensible-editor doesn't exist on other distributions, and of course xdg-open will fail in a text-only environment, but it couldn't hurt to try as many options as possible, if you think it's important that a desktop user can see their happy shiny gedit or kate instead of scary old vi or nano. ;)
The way crontab and sudoedit work is also by making a file in /tmp. git puts it under .git, and svn actually puts it in the current directory (not /tmp).
The way svn and mercurial do it is by making a file in /tmp.
BTW, you don't need a MYAPPEDITOR, on nix there's EDITOR already present.
Since you mention svn in your post, why not just follow the same methodology? svn opens a file with a particular name with whatever $EDITOR (or $SVN_EDITOR) contains - this might actually require some work on your part; determining the parameters to each supported editor. In either case, you have the name of the file that was saved (or the error code of the application if something failed) and you can just use that.