Command line arguments #111
Comments
ghost
assigned 
|
I have had a few requests for this, so I'm likely to implement commandline support eventually. |
|
Thanks for the information. |
* part of issue #111 * add getopt dependency for MS compilers * enable the provision of an ISO as parameter * also fixes shadowed sevenzip_path in vhd.c
|
Thanks for the work on command line request. I also noticed that you added UEFI support a while ago. Thanks for adding UEFI support. I didn't know I needed it- until today! |
|
Can you create readme file with all current and future command line switches that RUFUS uses. |
|
Try |
|
That works, but I do not see any partition commands. Thank you. |
|
That's because, as I said, there is very limited commandline support available, and what you seek has not been implemented. Realistically, I don't expect to implement the feature you are after for at least a year or two, at best, if at all. Sorry. |
|
This being said, creating an UEFI-NTFS drive from the commandline should be relatively easy if you know what you are doing:
That's it. |
|
I see, that sucks. I do not have the ability to do that with disk part and do not have knowledge in grub4dos to do that. Unless you are will to lay it out for me, because it does not sound like a lot of steps. Attach below is currently what I have to do to make this work. Thank you.Const HKCU = &h80000001 ANS = Msgbox ("You are about to create USB Imaging Drives, using USBMAKER.exe. Any USB Mass Storage drives that is attach to the system will be converted into a USB-Imaging Drive." & vbNewLine & vbNewLine & "Would you like continue?", vbYesNo + vbCritical, " USBMaker") If DeviceFound = False Then 'Cleaning all Drives and Pre them for RUFUS 'Preping Drive for UEFI Formating 'Set up for RUFUs do while UEFICount > 0 'Sending keys to App to complete task 'Close Program and delete Dword 'Math 'Add WINPE Files and Image File For i = 0 To Len(RDrives) MsgBox "USBMake.exe have complete all task and have succefully create these USB Image Drives: " & RDrives |
|
I'm afraid you'll have to seek for help elsewhere then. I provided you the global steps and that's as far as I'll go. |
|
Well thank you for your support on this, I hope your app soon will have the command line switches. That is something I am willing to donate for. I will try some VBS forms and see if anyone has figured out how to do this using WMI commands in VBS. Thank you for your time. |
|
We may also want to pick up part of the no-GUI patches from here. |
|
I love your tool, especially the UEFI-NTFS thingy :) However, I hoped at least the partitioning and applying uefi-ntfs.img part would already be available as command line because there is no (portable) command line tool that allows creation of 256 KB sized partitions. I already do everything like merging Windows 10 Pro and Enterprise images, applying Language Packs, integrating updates and various software and creating an ISO file. The only thing I can't do is creating a bootable BIOS/UEFI thumbdrive. |
Commandline is very low priority, because I'm afraid this is not a feature that will help the vast majority of Rufus users, and it is not in very high demand (even if those who demand it might be vocal... which is not still not the same as being in high demand).
I hope you can appreciate that this is not really a Rufus problem. As stated in the FAQ: "The scope of Rufus is to create bootable USB drives, and that's about it. Anything else, such as duplicating what diskpart, or other utilities do, is out of scope". However, please be aware that, outside of commandline support, Rufus already allows you to create BLANK UEFI:NTFS drives in advanced mode (you get to advanced mode by clicking on the white triangle next to Options). That means it will create the 256KB UEFI:NTFS partition and format the drive to NTFS allowing you to copy content. |
|
Hello, I just read your project FAQ and I saw that you planned to include command line feature, even if it's a sysadmin/expert/confirmed user feature. Great! Even if there isn't a checkbox in Rufus settings to be the default handler for ISO (it could be possible because Rufus is already elevated), I just want it to use the %1 ISO file if I run "rufus.exe" %1 as admin. Thank you |
|
I would like it so you could specify everything, and not even have to open a GUI. |
|
Sorry, as much as I'd like to satisfy all requests ASAP, there's only so much time I can spare for development, so I have to prioritize, and unfortunately, command line usage is a lot lower on my priority list as other features that will benefit a much larger number of people. I am still committed to adding proper command line support to Rufus, but it's not going to happen fast I'm afraid... |
|
📌 Hope to see CLI implemented when it is time for it! |
|
@pbatard Please check out docopts. It could be your most straightforward and easiest way to implement the CLI without having to doxigen and getopts etc with a thousand switches and parsers. |
|
I'm absolutely fine with getopts, which does its job splendidly as far as I'm concerned (and with a low footprint, which is precisely what I want). So the parsing of arguments is a non-issue there. The real delay comes from spending time to properly implement the commands themselves (not their parsing) and especially the ones that relate to existing UI features. Also, remember that adding commandline support is a very low item on my list, compared to other features, so it is going to be delayed. Plus, I have a fairly clear idea of what I want to do with regards to commandline implementation, which will require a lot of "behind the scenes" work (similar to what happened for the 3.0 UI redesign, which pretty much required me to drop everything else for about 6 months), so I need to get to a point where I expect to be able to allocate about the same amount of time without more important things getting in the way... which, considering the priority-level of this feature, is unlikely to happen for another few years... |
|
@pbatard Understandable. Can you make a TODO list of the required low-level changes in the repo, though? I would appreciate to read all the behind-the-scenes plans you have on the CLI implementation :) Also, this might help to give possible contributors a clear idea of how to implement such a thing in the coming years! |
I'm afraid not. Even as this is an Open Source project, there's a good reason I do use codenames, such as DealBreaker or StreetFighter for features that I am planning to implement, and that I don't want other people to know about or put their nose in before I have some tangible ALPHA version to show for. I've been developing software long enough to have come to an understanding that feedback on super moveable targets does not help anyone, be it the developer or the end users. It's much better to have something to show for, even if it's early stage, before inviting feedback. But I'm a long way to have anything like that as far as commandline is concerned. And again, I have to stress out, commandline support is at least years away, so there's no way I'm going to go into details on how I'm planning to address something that is that far out, as things can and do change when a lot of time elapses. |
|
I understand. In any case, I appreciate the work you put in Rufus; and I'm sure we all can wait until this feature request comes up on the list. (I have to admit that I'm just now realising your use of codenames here.) Thanks for being open with us, and as a developer myself, I hope that someday I can reach the level of software wisdom you have. |
|
With no intention to tarnish this project in any way, does UNetBootin even provide a command line interface? |
|
A lot of us could really use command line options. I'm needing to create an iso from a usb drive from the command line. |
|
Doesn't |
|
Yes, however on Windows, I don't think |
|
Could what currently exists for command-line support be placed in the wiki somewhere? I'm sure for some of us it's what we were looking for, just the option to choose what iso to reference (for example in a carefully crafted Windows shortcut) allows us to skip a step when creating regular USB drives (for example for building Windows PE boot drives). |
|
I know there's already command line switches and tweaks, but how long do you think it'll be until you make it where someone can configure all the settings and can deploy ISO images via the command line without needing the open the GUI? |
To be brutally honest, I don't see that happening for at least 3 more years, and in all likelihood, you might very well double that timeframe. Doing this properly requires a massive effort of dissociating the UI from the core functions, and, quite frankly, when I do that, I'd rather not use the old .rc/GDI way of displaying UI elements but XAML. And I'm afraid I don't see Microsoft having finalized enough of how they really to do to transition win32 into XAML (yes there exists XAML islands) to make that attractive to pursue just yet, especially as I usually try to support Windows platform for at least one more year after Microsoft sunsets them, on account that Rufus is used by people running these platforms precisely to transition to newer Windows version. However, XAML Islands require Windows 10 version 1903 or later, and is not compatible at all with Windows 8.1, which means that, even if I were to require that pre 1903 Windows 10 users using Rufus upgrade, I still have to wait for Windows 8.1 EOL + 1 year to be in a position where I am comfortable enough that I am not going to anger the Rufus user base by telling them to upgrade their platforms if they want to use the current version of Rufus, which basically means that I have to wait until the end of 2023 (especially as I want to see if Microsoft are actually that committed to XAML island, or if .NET Core is not going to throw them to introduce a completely different paradigm in order to have a cross platform UI framework). So, the smart thing for me to do on this is to wait for a few more years, when I will be in a position to actually split Rufus-core and Rufus-UI without thinking "I wish I had waited a couple more years, so that I could have gone with a technology that is much better for the long run" or without angering a significant number of Rufus users who are running versions of Windows that are close to being obsoleted. Plus, as I said, even if using a framework that should make it easier, this will still be a massive undertaking (I estimate at least 4 months of full time hard work), and I'm way too busy for the foreseeable future to get into something like that. As such, considering that the requests for commandline Rufus aren't that numerous, the smartest course of action I am continuing to see here is to wait until the vast majority of Windows users have actually upgraded to using Windows versions that should make it a lot easier for me to finally implement this request, even if it's likely to take quite a few more years. |
|
Would adding extra switches that runs it but still uses the ui be easier? i.e. automated ui interaction but possibly allows it to be minimized. Just an idea. |
|
That would be pain to maintain, as every time I change something (such as adding or altering a popup), I'd need to spend time adding new UI automation or making sure that the current one doesn't break. IMO, if you really can't wait for Rufus to work without user interaction, then it's up to you to spend time with one of the many UI automation solutions that exist to automate and maintain whatever workflow you want to Rufus for. In other words, you are not as stuck as you may think you are if you have a need to use Rufus in a non interactive manner. But of course this means that, instead of asking someone else to invest a lot of their time so that you can use Rufus in an automated fashion in your workflow, it becomes up to you to provision that effort, which I guess is less endearing than the prospect of having someone else doing it for you entirely for free... 😉 |
|
What about providing Rufus as a library, and then different developers can maintain the CLI and GUI extensions to the library |
|
The problem is that people imagine that the code is already relatively well broken down between core and UI. That is NOT the case. At all. Dissociating Rufus core from the UI, be it as a library or anything else, will take months of work. Full time work. I know this because that's what the 3.0 UI redesign took, and that was a simple "UI" upgrade (the kind that, any external person, who thinks that we are using MFC or XAML, rather than base Win32 APIs would expect to take one week to do tops). So any progress on this requires dissociating core from UI. And this is the part that requires extensive work. There is no easy way out to sinking in that work, regardless of how you approach the problem. And that I why I am currently deferring this issue. |
|
@pbatard I can understand this issue, I hope the others also will. The code is already here, if I had the skill, I would work on a PR that would isolate the core from the UI, so both the library proposal and the most wanted CLI feature could happen. Until it is possible for the separation of core from UI, it's not feasible to provide any other method of invoking the core functions, than actually calling them from the UI. In the meantime, thank you for working and improving upon other parts of Rufus. I truly appreciate your work. |
I was taking a look at it(for fun and for profit) and it seems like one would have to go through 5-6k loc (most of it in rufus.c and ui.c) minimum to do anything meaningful. Let's see how long it takes for me to give up 😅(considering I don't even know C, lol) |
|
Hello, |
|
At first, thank you for all the time and effort you put into this project. Requires a lot and needs to be respectfully appreciated. 👍 I'd like to ask if you could add a print out version string flag/switch, e.g. like Regards! |
|
Considering that you can get the version information by right clicking on the file to access its properties (there's probably a PowerShell command that can report the same on the command line) or on the title bar of Rufus or in the About dialog, and that Rufus is first and foremost a full GUI application, I may add what you request, but it's going to be super-low priority for me. I hope you realise that Rufus is very different from a UNIX commandline application, where finding the version of the executable pretty much demands that there exist an commandline option for it. On Windows, and especially for UI applications, there really isn't much need for an executable to have such a commandline option... |
Thank you for noticing and as being said, I really appreciate your efforts overall. Also I'm not trying to argue with you about the meaningfulnes of this suggestion. This propably only matches a few special use cases where people are interested in getting the rufus binary version via bat/cmd. For me this would simply be a nice addition and shouldn't be that hard to realize from a programmers viewpoint afterall. Just wanted to let you know that. Nothing else.* *In my opinion this small suggestion rather fits an existing (related ticket) comment than a new enhancement/feature request ticket |
I hear you. But you'd actually be surprised how simple operations like retrieving the version of an application are being made overly complicated by Microsoft. This is actually a perfect example of how a seemingly innocuous feature that "shouldn't take that long to add" is actually a not-so-simple job with major ramifications on both the existing code and the security of the application... Again, that's not to say I won't add this feature, but it's definitely not going to be a 5 minutes job, and because of that, and because of the low benefits for users I expect from it, it's going to be very low priority. |
|
loving the option for -i Only additional option beyond what you have today I could request is -l (lowercase L) for adjusting the label. |
Apologize for being late. I didn't expect version administration/polling to be that hard when trying to use windows and the version.dll library especially. My original request was targeting at the binary to output it's own version so other utilities are able to grab the version string and act accordingly (check for automatic updates). Another approach that came into my mind afterwards was to utilize a package manager for version managing, because there are already packages available for this repo (e.g. as listed here and here). So I eventually decided to go for this. |
|
@pbatard I appreciate your focus on the core scope of Rufus, and not letting the desire for (nice) features hurt that core scope. All of your reasoning for what you are and are not doing makes sense to me. |
|
I found the way in source static void PrintUsage(char* appname)
{
char fname[_MAX_FNAME];
_splitpath(appname, NULL, NULL, fname, NULL);
printf("\nUsage: %s [-x] [-g] [-h] [-f FILESYSTEM] [-i PATH] [-l LOCALE] [-w TIMEOUT]\n", fname);
printf(" -x, --extra-devs\n");
printf(" List extra devices, such as USB HDDs\n");
printf(" -g, --gui\n");
printf(" Start in GUI mode (disable the 'rufus.com' commandline hogger)\n");
printf(" -i PATH, --iso=PATH\n");
printf(" Select the ISO image pointed by PATH to be used on startup\n");
printf(" -l LOCALE, --locale=LOCALE\n");
printf(" Select the locale to be used on startup\n");
printf(" -f FILESYSTEM, --filesystem=FILESYSTEM\n");
printf(" Preselect the file system to be preferred when formatting\n");
printf(" -w TIMEOUT, --wait=TIMEOUT\n");
printf(" Wait TIMEOUT tens of seconds for the global application mutex to be released.\n");
printf(" Used when launching a newer version of " APPLICATION_NAME " from a running application.\n");
printf(" -h, --help\n");
printf(" This usage guide.\n");
} |
|
@pda8888, there was no need to look at the source. Typing |
|
I see that -l is locale now, maybe -t (mnemonic for title) and --title for a label override, perhaps with --label as an alias? |
First of all- thank you for a great utility!
Does Rufus support command line argument? So that you can specify an ISO when starting Rufus. Something like...
If not, would you consider adding that feature?
Thank you for your time.
Best regards,
Bob
The text was updated successfully, but these errors were encountered: