InterviewSolution
Saved Bookmarks
InterviewSolution
| 1. |
Solve : What is the optimal high level language for batch files? |
| Answer» <html><body><p>Quote from: BC_Programmer on December 13, 2011, 03:20:14 PM</p><blockquote>If you are asking what other high-level language would be the easiest to port to, well... none of them. You would end up rewriting it from scratch anyway, which makes the question sort of moot.<br/></blockquote> Not entirely true. Powershell will still recognize most batch commands. Also allows you to utilize VBScripts within the same "program." Might be the only other language available that would allow <em>some</em> porting options from batch.<br/><br/>Still, the OP may be much better off utilizing an actual programming language to accomplish whatever tasks that are needing accomplishment. <br/><br/>Or you could always reasearch and <a href="https://interviewquestions.tuteehub.com/tag/try-1428546" style="font-weight:bold;" target="_blank" title="Click to know more about TRY">TRY</a> writing your own program in machine language as well. Talk about efficiency. You take out the compiler aspect completely. Of course it will likely only work for your particular chipset, but it will work nonetheless. Quote from: Raven19528 on December 13, 2011, 04:05:04 PM<blockquote>Not entirely true. Powershell will still recognize most batch commands. <br/></blockquote> It doesn't recognize any batch commands. It does have a few commands that happen to have the same name as existing batch commands. Dir acts completely differently and is just an alias for ls, much as it is on most modern distros. sort doesn't execute the sort.exe 'external' command, and instead invokes the built-in sort cmdlet, which has a different syntax and usage. Things like <a href="https://interviewquestions.tuteehub.com/tag/setlocal" style="font-weight:bold;" target="_blank" title="Click to know more about SETLOCAL">SETLOCAL</a>, the addressing of variables using either percent signs or exclamation marks, and several other frequently used features are nonexistent or drastically changed in Powershell. set works differently. for is completely different altogether. there aren't goto's or labels, those would have to be replaced by functions. Commands like "Start", "fc", "if" and so forth are either noexistent (if), have completely different functions altogether (fc= File Compare in batch, Format_Custom cmdlet in Powershell), or have different parameters, limitations, and fiobles (start)).<br/><br/>Any non-trivial Batch script will end up being pretty much rewritten to be "ported" to Powershell. Powershell is closer to Bash than it is to Batch.<br/><br/> Quote<blockquote>Also allows you to utilize VBScripts within the same "program."</blockquote> No idea what this means. VBScript- and in fact the ActiveX Scripting Host- can be accessed from powershell, but I can't think of a way to integrate VBScripts into a Powershell script any better than the same type of echo method used in a batch for that purpose. The "integration" basically consists of still allowing you to execute CScript.exe from powershell.<br/><br/> Quote<blockquote> Might be the only other language available that would allow <em>some</em> porting options from batch.<br/></blockquote> It offers no more portability for batch code than Bash. Nobody opens up a Batch Script in gedit and screws around with it until it works. You rewrite it using the native functionality of Bash; same for Powershell.<br/><br/><br/> Quote<blockquote>Still, the OP may be much better off utilizing an actual programming language to accomplish whatever tasks that are needing accomplishment. </blockquote> Except Batch is "an actual programming language" as is Powershell. Thing is, it already sounds like they accomplished what they want in Batch, thus Salmon Trout's original question as to why they need to do anything further.<br/><br/> Quote<blockquote>Or you could always reasearch and try writing your own program in machine language as well. Talk about efficiency. You take out the compiler aspect completely. Of course it will likely only work for your particular chipset, but it will work nonetheless.<br/></blockquote> I know this was probably facetious, but the compiled result from most modern compilers will be many times faster and more optimized than Machine code, <a href="https://interviewquestions.tuteehub.com/tag/unless-774664" style="font-weight:bold;" target="_blank" title="Click to know more about UNLESS">UNLESS</a> that person has spent the last 40 years hand-tuning machine code. Same for Assembly, which would have been far saner to mention since there isn't a huge difference between Assembly and Machine code, that's why Assembly is assembled, it's basically a process of substitution of Assembly keywords with the appropriate machine instructions. Also, most of the "Batch compilers" I've seen tend to use a 32-bit executable to wrap the batch file which is no less machine-dependent than hand-tuned x86 Assembly. Well thank you for tearing apart my post. *goes into corner and cries ...comes back*<br/><br/>Yes I was being facetious with that last comment. I mentioned it because I recall a homework assignment that had us do the machine code for an 8088 chipset that would assign two variables, add them together, and output it to the screen. It was ridiculous the amount of work that went into that. I was just happy that we were able to write it in hex rather than binary.<br/><br/>As far as the actual programming language comment, that was written hastely and was inaccurate. I suppose the more correct term would be to say a programming language designed to output .exe files. Powershell is not one of them, I know.<br/><br/>For Powershell, I haven't actually dabbled too much into it, and yes the stuff I did dabble in was a pretty trivial batch file. Powershell documentation had either the implicit or explicit connotation that many batch commands worked just as well in Powershell, or perhaps that the batch functionality was still supported through Powershell. It's been awhile, so I'm not certain.<br/><br/>You have been very helpful in teaching me to stick with what I know and not to talk about the things I don't, as that's when the beatings start. You have effectively paddled me in front of the school assembly, so I will now lick my wounds and live to program another day. Quote from: Raven19528 on December 13, 2011, 06:02:01 PM<blockquote>Yes I was being facetious with that last comment. I mentioned it because I recall a homework assignment that had us do the machine code for an 8088 chipset that would assign two variables, add them together, and output it to the screen. It was ridiculous the amount of work that went into that. I was just happy that we were able to write it in hex rather than binary.<br/></blockquote> My main point was that the people writing compilers are better than the vast majority of programmers at assembly... they know all sorts of tricks and implement them into the compiler.<br/><br/><br/> Quote<blockquote>I suppose the more correct term would be to say a programming language designed to output .exe files. </blockquote> Not really. There is no reason so far that they've given to use a language that makes executables. If their goal is "I just want executables" than, well, that's sort of a silly goal.<br/><br/> Quote<blockquote>For Powershell, I haven't actually dabbled too much into it, and yes the stuff I did dabble in was a pretty trivial batch file. Powershell documentation had either the implicit or explicit connotation that many batch commands worked just as well in Powershell, or perhaps that the batch functionality was still supported through Powershell. It's been awhile, so I'm not certain.</blockquote> Everything I wrote I <a href="https://interviewquestions.tuteehub.com/tag/verified-2320336" style="font-weight:bold;" target="_blank" title="Click to know more about VERIFIED">VERIFIED</a>. you can run batch scripts from powershell but then cmd.exe is what interprets them, not Powershell. This can be useful so that if something comprises of several batch files, rewriting them in powershell could be done top down, and the powershell can call batch files, until those batch files are rewritten in powershell.<br/><br/> Quote<blockquote>You have been very helpful in teaching me to stick with what I know and not to talk about the things I don't, as that's when the beatings start. You have effectively paddled me in front of the school assembly, so I will now lick my wounds and live to program another day. <br/></blockquote> Sorry that's what happens when I drink too much coffee. I guess in further analysis that I dont really need to compile them as they run perfect in their native batch format (.cmd)<br/>The real need for comiling was for speed and not much else.<br/>i guess that i just will pick the language that seems to <a href="https://interviewquestions.tuteehub.com/tag/meet-251351" style="font-weight:bold;" target="_blank" title="Click to know more about MEET">MEET</a> the needs of the batch file (mainly set envir var's)<br/>and no {shudder} to writing in machine language, lol<br/>but will take a look at powershell too.<br/> <br/>many thanks for all the comments, great to learn at U of CH <br/> <br/> Quote from: BC_Programmer on December 13, 2011, 03:20:14 PM<blockquote>OK, but why do you need to compile them?<br/></blockquote> Quote from: Salmon Trout on December 13, 2011, 03:41:03 PM<blockquote>skorpio07, we keep asking you:<br/></blockquote> Quote from: Raven19528 on December 13, 2011, 04:05:04 PM<blockquote>Not entirely true. Powershell will still recognize most batch commands. <br/>Or you could always reasearch and try writing your own program in machine language as well. Talk about efficiency. </blockquote> Quote from: BC_Programmer on December 13, 2011, 06:27:32 PM<blockquote>This can be useful so that if something comprises of several batch files, rewriting them in powershell could be done top down, and the powershell can call batch files, until those batch files are rewritten in powershell.</blockquote> Quote from: skorpio07 on December 14, 2011, 07:57:11 AM<blockquote>The real need for comiling was for speed and not much else.</blockquote> So you were looking to slow down your batch file! J/K. LOL!<br/>I am sure you are aware now of why it wasn't speeding it up but actually slowing it down.i never got to the point of being able to test the speed issue, as the compiled program wasn't working as expected. working on a freebasic version, hopefully things work out.<br/> <br/> Quote from: Squashman on December 14, 2011, 08:28:05 AM<blockquote>I am sure you are aware now of why it wasn't speeding it up but actually slowing it down.<br/></blockquote> so this is more or less solved...<br/> <br/>im going to use freebasic unless there are limitations when doing the port from batch.<br/> <br/>many thanks to all for your input and suggestions<br/> <br/>thanks<br/> <br/></body></html> | |