TLTR

Shortcut – record, save & execute your most used scripts in the terminal

Example:

sc fe be – boots your fe and be project in two separate terminal tabs

sc my_dir # Instead of typing N cd, move straight to the directory

SUPPORTS: iTerm, Terminal

Intro

A year or so ago I’ve started being tired of navigating to some directories over and over again. Same with running scripts for booting my project.

At that time I’ve been doing some custom scripts + aliases to make my work flow a bit better, but didn’t really like that approach for some reason, as I thought having CLI tool for creating and managing those scripts would be much better (more intuitive) and so I have quickly written a prototype.

Around a week ago I thought it actually could be useful for others + maybe someone would want to contribute and make it more useful and less buggy.

Basically the flow looks like this:

1. sc --record – after running it you will execute

2. sc – executes the saved script in the new tab

In the case above it opened a new tab and immediately executed the script moving you to the Desktop

I made it so it opens by default in the new tab, as I usually use it to boot my projects with indefinitely running commands for booting my projects.

There are other commands that I’ve added like –list, –edit, so you can quickly check the saved scripts and edit them in vim as well.

Let me know what you think, maybe you have some ideas for improvements?

The post Shortcut your way through the terminal 🌀 appeared first on ProdSens.live.

Welcome to an exciting journey into the world of command-line interface (CLI) tools using JavaScript.

In this guide, I’ll walk you through creating a CLI tool that sets up a basic project structure, explaining every step and piece of code to ensure you can follow along.

Setting Up Your Development Environment

Before we dive into the world of CLI tools, let’s set up our environment:

1. Install Node.js and npm: Head to Node.js’s official website and download the recommended version. Installing Node.js also installs npm, the package manager you’ll use to handle JavaScript packages.

2. Verify Your Installation: Ensure everything is installed correctly by opening your terminal and running:

   node --version
   npm --version

Seeing version numbers confirms you’re all set!

Building Your CLI Tool: Project Setup Automation

Our goal is to create a CLI tool that automatically generates a basic project structure, saving you the hassle of manually creating folders and files every time you start a new project.

Step 1: Kickstarting Your Project

1. Create a Project Directory: This is where your CLI tool’s code will reside.

   mkdir my-project-setup
   cd my-project-setup
   

2. Initialize Your npm Package: This step generates a package.json file, which is crucial for managing your project’s dependencies and configurations.

   npm init -y
   

Step 2: Crafting Your CLI Application

1. Create the Main File: Name this file index.js. It will contain the logic of your CLI tool.

2. Incorporate a Shebang Line: At the beginning of index.js, add:

   #!/usr/bin/env node
   

   This line tells your system to use Node.js to execute this script.

3. Implementing the Logic: The code below creates a predefined project structure with directories and files:

   const fs = require('fs'); // File System module to handle file operations
   
   // Define the project structure: directories and their respective files
   
   const projectStructure = {
     'src': ['index.js'],
     'public': ['index.html', 'styles.css'],
   };
   
   // Iterate over the structure, creating directories and files
   
   Object.entries(projectStructure).forEach(([dir, files]) => {
     fs.mkdirSync(dir, { recursive: true }); // Create directories
     files.forEach(file => fs.writeFileSync(`${dir}/${file}`, '')); // Create files
   });
   
   console.log("Project structure created successfully!");
   

   Here’s what each part of the code does:

• Require fs module: This is Node.js’s file system module, which you’ll use to create directories and files.
• Define project structure: We specify which directories to create and what files they should contain.
• Create directories and files: Using fs.mkdirSync and fs.writeFileSync, the script creates each directory and file according to the structure defined.

4. Make Your Script Executable: Modify package.json to include a "bin" section. This tells npm which command should execute your script:

"bin": {

  "setup-project": "./index.js"

}

Step 3: Testing and Linking Your Tool Locally

Before sharing your tool, test it:

1. Link Your Tool: Run npm link in your project directory. This command creates a symlink that allows you to run your CLI tool from anywhere in your terminal.

2. Run Your Tool: Simply type setup-project in your terminal in project’s directory. If everything is set up correctly, you’ll see the “Project structure created successfully!” message, with the project structure as mentioned.

YES, THAT’S ALL IT TOOK!

Step 4: Enhancing Functionality

Your tool now automates project setup, but there’s room for improvement. Consider adding more features or handling user input to customize the project structure. Explore packages like yargs for parsing command-line arguments. You can learn more about yargs through their official documentation here.

Step 5: Sharing Your Tool on npm

Ready to share your CLI tool with the world? Here’s how:

1. Sign Up on npm: If you don’t have an account, create one at https://www.npmjs.com/signup.

2. Log In via Terminal: Run npm login and enter your npm credentials.

3. Publish Your Package: In your project directory, execute npm publish.

Congratulations! Your CLI tool is now available on npm for everyone to use.

If you have followed me till here, do checkout my first CLI tool I made in Javascript, and published on npm: Naturalshell. Naturalshell provides AI in your terminal, no need of memorising shell commands now!
You can checkout the npm package here and the github repository here.
Do drop a , and feel free to add new features and build on naturalshell with me!

This tool leverages AI to parse natural language and provide shell commands to users based on their needs. Beyond just providing commands, it also offers concise explanations, ensuring users not only know what to do but understand how it works. With the added convenience of editing commands directly within the tool and the ability to execute them immediately, NaturalShell delivers a user-friendly, intuitive experience

Wrapping Up

You’ve taken a significant first step into the world of CLI tool development with JavaScript. By building a simple yet functional tool, you’ve learned the essentials of creating, testing, and publishing CLI applications. Keep experimenting, learning, and building. The command line is a powerful ally, and now, it’s yours to command. Happy coding!

If you found this guide helpful and created your own awesome CLI tool, I’d love to see it! Please share your GitHub repositories in the comments section below. Let’s build together!

The post A Guide to Building CLI Tools in JavaScript appeared first on ProdSens.live.

If you’re working on a macOS system and encounter an application that’s not responding, you know how frustrating it can be. While the graphical interface offers ways to force quit applications, sometimes you may need or prefer to do this from the command line interface (CLI). Whether you’re remote accessing a system, prefer using the terminal, or are in a situation where the GUI is not accessible, knowing how to handle this via CLI can be incredibly useful. Here’s a step-by-step guide on how to force quit unresponsive applications using the command line on macOS.

1. Finding the Process ID (PID)

The first step in forcing an application to quit is identifying the process ID (PID) of the application. The PID is a unique number that macOS uses to refer to each running process. There are a couple of ways to find the PID of an unresponsive application:

Using ps aux:

• Open the Terminal application.
• Type ps aux and press Enter. This command lists all running processes on the system.
• Look through the list for the name of the unresponsive application. Next to it, you’ll see a number, which is its PID.

Using pgrep:

• Alternatively, you can use the pgrep command for a quicker way to find the PID. Simply type pgrep [application name], replacing [application name] with the name of the program. For example, pgrep TextEdit will return the PID for TextEdit if it’s running.

2. Force Quitting with the kill Command

Once you have the PID, you can proceed to force quit the application using the kill command.

• In Terminal, type kill [PID], replacing [PID] with the actual process ID of the application you want to quit. For example, kill 12345.

• If the application doesn’t quit with the standard kill command, you can use a stronger signal, -9, to force quit. Type kill -9 [PID], for example, kill -9 12345. This sends a SIGKILL signal, which immediately terminates the process.

3. Using pkill to Directly Force Quit

If you prefer not to look up the PID, you can use the pkill command to force quit an application by its name.

• Simply type pkill [application name]. For instance, pkill TextEdit would force quit TextEdit.

Caution

While force quitting applications can be necessary, it should be done with caution. Unsaved data may be lost, and there’s always a slight risk of causing system instability. Always attempt to allow the application to respond on its own or try to close it normally before resorting to force quitting.

Conclusion

Understanding how to manage unresponsive applications through the CLI can be a powerful addition to your troubleshooting toolkit on macOS. Whether you’re a developer, system administrator, or just prefer using the terminal, these commands offer a quick and effective way to regain control over your system when applications freeze or become unresponsive.

Remember, with great power comes great responsibility. Use these commands wisely and always ensure you have saved your work before force quitting any application.

The post How to Force Quit Unresponsive Applications via CLI on macOS appeared first on ProdSens.live.

Ember pioneered the standardised usage of global cli tool. This is a perfect way to give new users a good onboarding experience as well as existing users power tools for daily usage.

Config for ember-cli lives in ~/.ember-cli and is merged with my-project/.ember-cli file, if applicable.

The format of .ember-cli file is as follows:

Command line options are passed in a dasherized form on the command line but they must be in camel cased in .ember-cli.

So you can run ember help in your terminal and then use the formula above to convert the cli options to config file options.

Example

This is the global ~/.ember-cli I’m using in my setup:

{
  "welcome": false,
  "packageManager": "pnpm",
  "embroider": true,
  "typescript": true
}

Title image generated by Midjourney via prompt: “Command line ninja; The ninja is actually a hamster; –ar 16:9”

The post Ember-cli config appeared first on ProdSens.live.

When working with Lumen applications, every developer anticipates that the framework will have fewer native features when compared with Laravel. Different from its counterpart, which is intended to build full-featured applications, Lumen is intended for building smaller, faster microservices and lightweight APIs.

One thing not present in Lumen that I find hard to work without is a REPL. Even though the framework has fewer features than Laravel, it still offers database, cache, events, ques, and so on, but believe it or not, Lumen doesn’t offer a REPL out of the box.

Fortunately for us, the process of making a REPL available to a Lumen application is not complex, and we can achieve it with a few steps.

Content

• What is a REPL?
• Require dependency
• Define service provider
• Run the tinker command

What is a REPL?

Before we start, let’s explore what a REPL is. The acronym stands for Read-Eval-Print Loop and allows developers to enter commands or code snippets, which are then read, evaluated, and have their results printed back to the developer. This loop continues, making it an excellent tool for quickly experimenting with code, testing small pieces of code, and learning new programming languages or libraries.

Tinker is a REPL built over psysh which is a general-purpose REPL for PHP. Since a Laravel application is not plain PHP and has states, databases, caches, events, and many more complex resources specific to the framework, it’s not possible to interact with the application the way one would expect just using psysh.

And that’s where Tinker comes into play, since it’s a psysh integration that implements all the specifics necessary for a developer to interact with Laravel in a REPL manner, no matter the resource or feature of the framework being accessed in the REPL.

If you are new to Lumen, you might wonder: Since Tinker is a Laravel REPL, why are we looking into it for a Lumen application since they are entirely different frameworks? Well, you are right; as the Lumen documentation states, they are in fact two different frameworks with intentional incompatibilities with libraries. However, Lumen was born out of Laravel, and it shares some of its foundations with its older sibling, which in some cases means we can use Laravel dependencies in Lumen, and Tinker is one of them.

Require dependency

Now that we have an understanding of a REPL and Tinker’s foundations, let’s, as a first step, add Tinker as a dependency to our project. Below is the command you have to run to add Tinker as a development dependency to Lumen.

composer require --dev laravel/tinker

Define service provider

The Tinker dependency was added to the project; the next step is to register Tinker’s service provider at bootstrap/app.php. In Lumen, you typically register service providers in the bootstrap/app.php file to enable various functionalities within your application.

A service provider is a way to bind classes into the service container, configure services, and perform other setup tasks. Registering Tinker’s service provider in the bootstrap/app.php file is necessary to integrate the Tinker REPL into your Lumen application. By registering its service provider, you’re telling Lumen to make Tinker’s REPL available to you when you run the php artisan tinker command.

$app->register(LaravelTinkerTinkerServiceProvider::class);

Run the tinker command

Once the service provider is registered and Lumen has made Tinker’s REPL available, you can run php artisan tinker and interact with any Lumen component you need.

Now your Lumen application has a REPL configured for it.

Happy coding!

The post Tinker in Lumen: Your Ultimate Debugging Companion appeared first on ProdSens.live.

In order to fix a broken video where the camera stopped recording, I wanted to replace the part with a video with a sound wave overlay. There are many services for that, and it is also a feature of video editing software. But I am stingy and a geek, so I wanted to use FFMPEG on the command line instead. This also allows for batch processing.

Note: I didn’t embed the videos in this post but GIFs instead. The real videos play the video and audio and the sound wave moves accordingly.

Let’s say this is our original video:

This is what it looked like in the end:

Here’s the command I used to create the above version:

ffmpeg -i Understandable.mp4 
 -filter_complex "[0:a]showwaves=colors=0xff1646@0.3
 :scale=sqrt:mode=cline,format=yuva420p[v];
 [v]scale=1280:400[bg];
 [v][bg]overlay=(W-w)/2:H-h[outv]"
  -map "[outv]" -map 0:a -c:v libx264 -c:a copy 
  waveform-sqrt-cline.mp4

OK, let’s unwrap this:

• Understandable.mp4 is the input file
• 0xff1646@0.3 is the hexadecimal colour of the waves I want to create. The @0.3 is the opacity, 30%.
• The first scale is how the bars should be resized to stay in a certain range. I found squareroot to look the best. Other options are available in the documentation
• mode is what soundwave you want. This version, cline is a centered, filled line. Other options are point, line and p2p.
• scale is the size of the generated video of the wave, in this case 1280×400 pixels (as the video is 1280×1080)
• The overlay defines where on the background video the wave should appear. In this case centred in the horizontal direction and on the bottom of the video.
• waveform-sqrt-cline.mp4 is the name of the final video.

Change location of the sound wave

You can also center the sound wave in both directions using overlay=(W-w)/2:(H-h)/2:

ffmpeg -i Understandable.mp4 
 -filter_complex "[0:a]showwaves=colors=0xff1646@0.3
 :scale=sqrt:mode=cline,format=yuva420p[v];
 [v]scale=1280:400[bg];
 [v][bg]overlay=(W-w)/2:(H-h)/2[outv]"
  -map "[outv]" -map 0:a -c:v libx264 -c:a copy 
  waveform-sqrt-cline-centered.mp4

And the result looks like this:

Other sound wave styles

And you can change the output type to line and change the colour:

ffmpeg -i Understandable.mp4 
 -filter_complex "[0:a]showwaves=colors=0xffffff@0.5
 :scale=sqrt:mode=line,format=yuva420p[v];
 [v]scale=1280:400[bg];
 [v][bg]overlay=(W-w)/2:H-h[outv]"
  -map "[outv]" -map 0:a -c:v libx264 -c:a copy 
  waveform-sqrt-line.mp4

This is what the point to point mode looks like:

ffmpeg -i Understandable.mp4 
 -filter_complex "[0:a]showwaves=colors=0xffffff    
 :scale=sqrt:mode=p2p,format=yuva420p[v]; 
 [v]scale=1280:400[bg];
 [v][bg]overlay=(W-w)/2:H-h[outv]"
  -map "[outv]" -map 0:a -c:v libx264 -c:a copy 
 waveform-sqrt-p2p.mp4 

Adding a sound wave to a static image

If you only want the audio from a video and use a background image instead, this is what to use. This creates a 400×400 pixel video with the image as the background and the sound wave on top:

ffmpeg -i Understandable.mp4  -i chris.jpg
 -filter_complex "[0:a]showwaves=colors=0xff1646@0.3
 :scale=sqrt:mode=cline,format=yuva420p[v];
 [1:v]scale=400:400[bg];
 [bg][v]overlay=(W-w)/2:(H-h)/2[outv]"
  -map "[outv]" -map 0:a -c:v libx264 -c:a copy 
  static-image.mp4

FFMPEG is amazing

Granted, the syntax of FFMPEG is pretty nuts, but it is also super powerful. Want to know for example how I created the GIFs of this post?

First, I resized all the MP4s in the folder to 1/3 of their size and saved them as small*:

for f in *.mp4 ; 
do ffmpeg -i "$f" -vf scale=w=iw/3:h=ih/3 "small-$f" ;
done             

Then I took those and created gifs

for f in small-*.mp4 ; 
do ffmpeg -i "$f" -sws_dither ed -ss 5 -t 1 "e-$f.gif" ; 
done      

In English: Get all small-*.mp4s in the current folder, and create a GIF from second 5 of the video, one second long, using error diffusion.

Automate all the things!

The post Adding sound wave overlays to videos and pictures using FFMPEG appeared first on ProdSens.live.

As a computer user, you have probably heard about Command Line Interface (CLI) and Graphical User Interface (GUI). CLI is a method of interacting with a computer system through text-based commands, while GUI provides a visual interface with icons, menus, and windows. While GUI is more commonly used among computer users, CLI offers several advantages that make it a more efficient option. In this article, we’ll explore the differences between CLI and GUI and dive into five key reasons why you might want to consider using CLI over GUI.

What is Command Line Interface (CLI)?

Command Line Interface (CLI) is a text-based interface that allows users to interact with a computer system using commands. It is a way of interacting with a computer system that predates the development of a Graphical User Interface (GUI). With CLI, users enter a command into a text prompt, and the system responds accordingly. CLI is an efficient way to interact with a computer system, especially for experienced users who prefer to work with a keyboard.

The difference between CLI and GUI

GUI is a visual interface that allows users to interact with a computer system using graphical elements such as icons, buttons, and windows. GUI is more user-friendly than CLI and is the most commonly used interface among computer users. However, GUI has its limitations, especially when it comes to efficiency and flexibility. CLI, on the other hand, is a text-based interface that allows users to interact with a computer system using commands. CLI is more efficient and flexible than GUI, but it requires some level of technical expertise.

Advantages of CLI over GUI

CLI has several advantages over GUI that make it a more efficient option for certain tasks. Here are the top five advantages of CLI over GUI:

Improved efficiency with CLI

CLI is a highly efficient way to interact with a computer system, especially when it comes to performing repetitive tasks. With CLI, you can automate repetitive tasks using scripts, which can save you a lot of time and effort. In today’s fast-paced world, where efficiency and time-saving are crucial, CLI can help users achieve these goals. CLI also allows you to perform tasks faster than GUI, especially if you are an experienced user who prefers to work with a keyboard.

Flexibility and customization options with CLI

CLI is more flexible than GUI when it comes to customization options. With CLI, you can customize your environment to suit your needs, such as defining your own aliases and functions. You can also use CLI tools to perform a wide range of tasks, such as text processing, file management, and network administration.

CLI for automation and scripting

CLI is the preferred interface for automation and scripting. With CLI, you can create scripts to automate repetitive tasks, such as backups, updates, and installations. CLI scripting is also useful for system administration tasks, such as user management and network configuration.

CLI in programming and development

CLI is the preferred interface for programming and development. Many programming languages, such as Python, Ruby, and Perl, are designed to be used with CLI. CLI also allows you to use a wide range of development tools, such as Git, Docker, and Vim.

CLI for troubleshooting and system maintenance

CLI is an excellent choice for troubleshooting and system maintenance tasks. As opposed to GUI, CLI allows you to access system logs, diagnose issues, and perform system maintenance activities more effectively. CLI also offers greater control over system settings and enables you to interact with the system at a lower level, which can be helpful in identifying and resolving complex problems. Whether you’re an experienced system administrator or a curious user looking to dive deeper into your computer’s inner workings, CLI provides an efficient and flexible way to maintain and troubleshoot your system.

CLI tools and resources

Here are some popular CLI tools and resources:

• Bash: A popular shell for UNIX-based systems.

• Zsh: An alternative shell with advanced features and customization options.

• PowerShell: A CLI shell for Windows systems.

• Vim: A powerful text editor for CLI.

• Git: A version control system for software development.

• Docker CLI: A containerization platform for software development.

By using these tools, you can take advantage of the power and flexibility of CLI for programming, system maintenance, and automation.

Conclusion

In conclusion, Command Line Interface (CLI) is a more efficient option than Graphical User Interface (GUI) for certain tasks. CLI is more efficient, flexible, and customizable than GUI, and is the preferred interface for automation, scripting, programming, troubleshooting, and system maintenance. If you are a computer user who values efficiency and flexibility, then learning CLI is a valuable skill that can help you get the most out of your computer system. If you found this article informative, be sure to follow me for more articles like this.

The post 5 Reasons Why Command Line Interface (CLI) is More Efficient Than GUI appeared first on ProdSens.live.

Hey everyone,

I’m happy to announce that we have
released Reduct CLI client v0.7.0 with some minor improvements and bug fixes. We started using the tool in real applications and faced some problems exporting data from a ReductStore instance when the connection is slow and we have many entries to download asynchronously.

First of all, it wasn’t very convenient to count all needed entries in the rcli export command. Now we can use wildcards:

rcli export folder instance/bucket ./export_path  --entries=sensor-*

More over, the rcli export command used the query API with default TTL 5 seconds for a query. When the internet connection was slow, it may have taken more than 5 seconds to request the next record in the query. The query could expire and the CLI would receive the 404 HTTP error. Now the CLI client uses the TTL equal to the number of parallel tasks multiplied by the timeout. By default, the TTL is 50 seconds (10 parallel tasks * 5 second timeout). This makes the data export more robust and allows a user to change the TTL by using the parallel and timeout options.

rcli --parallel 5 --timeout 3 export folder  instance/bucket ./export_path # TTL is 15 second

if you have any questions or feedback, don’t hesitate to reach out in Discord or by opening a discussion on GitHub.

Thanks for using ReductStore!

The post CLI Client for ReductStore v0.7.0 has been released appeared first on ProdSens.live.