I use Vim every day to write shell scripts. I have been reading about the quickfix window, and I think it could speed up my productivity in the edit-run-fix cycle.
If I understood properly, I have to write my own errorformat function in order to Vim to be able to catch the errors and introduce them into the quickfix window. But this seems to be really complicated.
Is there an easier/more convenient way to take advantage of the quickfix window in Vim when writing Bash scripts?
Vim's quickfix window is designed to speed up the edit-compile-edit cycle. Since Bash scripts do not get compiled, we have to substitute something else for that step that can point out errors in the current script.
What you want is a static analysis tool for Bash scripts. There are two good ones: shellcheck and checkbashisms. You'll want to install at least shellcheck, as it's the more comprehensive of the pair, but installing checkbashisms will help catch a few more issues.
To integrate those two tools into Vim, you need a plugin called Syntastic. Check the project page for installation instructions.
Once you've got everything installed, you'll be able to get immediate feedback on basic issues in your Bash script:
Use :SyntasticCheck to force the checker to run
If you want the "quickfix" window to appear, run :Errors
Related
I am downloading data from a remote server using curl in Build Phases > Run Script. Downloading takes 5-15s, not that much, but multiple times a day it consumes considerable time. Is there a better way to skip a script than commenting it out? Ideally, it would be some kind of confirmation at compile time (e.g Do you really need to download X? y/n).
You can’t make the run script interactive in the console as far as I know. But you can use a shell conditional with an AppleScript interactive dialog, because AppleScript itself blocks while dialog is shown. See for example https://cantina.co/adding-interactivity-to-the-xcode-build-process/.
However, introducing uncertainty into a build is dangerous. Plus you’d never be able to automate the build. In my view you’d be better off flipping a custom build setting / environment variable.
I have a bash script that works at the moment. It gets an image and JDK 8 from a link and then runs a installer for the JDK 8 to move on to setting up another piece of software.
As I was debugging the script, I kept finding myself having to delete directories and even the java installation because when I introduce a fix and rerun the script, I have to wait for everything to download again and I have to worry about duplicate files messing up my current logic -which can probably be improved, but I'll go to the StackExchange Code Review site later.
At the moment, I would like to know what approaches there are to prevent commands -like downloading the JDK and running the JDK installer script all over again and others- from running again.
What kind of general approaches are out there for cases such as these?
For the JDK download and running the installer, I did think of simply checking for the existing of java on the system and if there is then bash would not not to run those commands.
However, there are other commands I do not want run and I do want to simply check, for example, the existence of certain files to prevent wget-ing them all over again and moving them -causing duplicates. (Should I maybe suck it up and do that anyway as that might be best practice?)
I did also think of perhaps, at each successful command, outputting like a 1 to a text file and mapping each line in that text file to the commands run in the script (like using an if statement to see if that command had a 1 or not in the text file) and if it was a 0, then the script would know only to run that command and never the 1s.
That sounded clunky to me and I am pretty sure that is not a good approach.
When doing significant refactoring using VSCode I have found running:
stack build --file-watch
in the integrated Powershell terminal invaluable. I was wondering if there was a way to somehow prepend a clear terminal command so I only see the last batch of errors.
Something like:
stack build --exec-before "cmd cls" --file-watch
Note exe-before is not a real stack command
Try ghcid. It's a program which does exactly what you want: run the appropriate command when a file changes, clearing the screen between changes. Have a look at this tutorial for more details. Plus, it looks like there's even a Visual Studio Code extension which runs it directly in the IDE!
There are a few extensions for VSCode which compile open files on the fly and populate PROBLEMS window with errors and warnings. From my personal experience I'd recommend Simple GHC which just works out of the box and quite stable.
I would like to dynamically debug a vim script. My current workflow is that I have the autoload plugin opened on a tmux pannel and the running application on the other pannel. I also set a tail -f vim.log and I launched vim with vim -V15vim.log. My goal is to monitor the execution of the plugin by adding plenty of echom.
Actually I was expecting something more useful that what I actually got.
I need to restart vim everytime I add a new echom
Nothing really useful is displayed on the log file vim.log
This method is obviously not the right one
I also tried to add breakpoints with breakadd func myfunc#test but it is not really working because the debugger windows interfers with the main window and change the way the plugin I am debuging behave.
How to improve my vim-script debug workflow?
HINT
I am actually trying to debug the vim-multiple-cursor plugin which does not work with a column block selection and virtualedit enabled. I would like to fix it.
:breakadd is the most powerful tool, but yes, its output and interaction may interfere with certain plugin actions, and trigger additional autocmds. It may help if you specify the optional [lnum] offset to only stop executing inside the function.
I need to restart vim everytime I add a new echom
It should be enough if you just :source the changed plugin script again. Scripts inside ~/.vim/plugin/ usually employ a multiple inclusion guard that you need to work around, though. My ReloadScript plugin can help with that.
Alternatively, the Decho plugin might offer a different approach worth looking at.
I am quite curious to know if there is a way to achieve the same that you get, when in Xcode you press cmd-u (or select Test from the menu).
I am writing some UI tests for an application, and would love to automate the whole thing.
So far, any attempt to automate via applescript has been quite unsuccessful (I told myself how hard it is to simulate 2 button pressed...); so I thought that maybe there is a proper way to just run the command line commands and have the simulator to pop and run the tests, like it does in Xcode.
Altho if this function was known, I would find something online, but it seems that there is no way to simulate the test command via console.
Am I missing something?
Have you checked out the xcodebuild command?
The man page says:
buildaction ...
Specify a build action (or actions) to perform on the target. Available build actions are:
test Test a scheme from the build root (SYMROOT). This requires specifying a scheme.
So, perhaps that will do what you want.