Stories with Tag shell script

• Automating the cleaning of macOS-specific ( ._ and .DS_Store) files on Eject

  permalink

  Posted: 2025-02-09 02:00:06

  Verbose tl;dr

  This blog post details how to automatically remove macOS-specific files (.DS_Store and ._*) from external drives upon ejection. The author uses a combination of AppleScript and a LaunchAgent to trigger a cleanup script whenever a volume is ejected. The script leverages dot_clean to efficiently delete these often-annoying hidden files, preventing their proliferation on non-macOS systems. This automated approach replaces the need for manual cleanup and ensures a cleaner experience when sharing drives between different operating systems.

  This blog post by "The Ginger Beard Man" details a method for automatically removing macOS-specific files, namely "._*" (AppleDouble files) and ".DS_Store" files, from external drives upon ejection. These files are created by macOS for various system-level functions, such as storing metadata and resource forks, but can be a nuisance on other operating systems and clutter shared drives.

  The author explains that while manually deleting these files is possible, it becomes tedious and error-prone, especially with frequent use of external drives. Therefore, they present an automated solution using a combination of AppleScript and the built-in eject command-line utility.

  The core of the solution revolves around a custom AppleScript that iterates through every mounted volume except the boot volume. For each volume, it checks if it's a local or network volume. If it's a local volume and the volume name doesn't match specific exclusions (in the provided example, "Time Machine" is excluded), the script constructs and executes a dot_clean command. dot_clean is another command-line utility, readily available through package managers like Homebrew, which efficiently removes the unwanted "._*" and ".DS_Store" files. After cleaning, the script proceeds to eject the volume.

  To seamlessly integrate this process with the system's eject functionality, the author replaces the default eject command with a shell script wrapper. This wrapper first calls the custom AppleScript to clean and eject the specified volume. This replacement is achieved by placing the wrapper script in a directory that precedes the system's /usr/bin in the user's PATH environment variable. Thus, when the user ejects a drive through Finder or the command line, the wrapper script is executed first, ensuring the cleaning process happens before the actual ejection.

  The author provides the complete code for both the AppleScript and the shell script wrapper, along with clear instructions on how to install dot_clean, create the necessary files, make the script executable, and adjust the PATH environment variable. They also emphasize the importance of understanding the implications of modifying the PATH and offer advice on reverting the changes if needed. Finally, they mention the option of adapting the script for specific needs, such as excluding different volumes or using alternative cleaning methods.

  • macOS
  • Mac OS X
  • file management
  • Automation
  • Cleaning
  • Eject
  • Disk Eject
  • Hidden Files
  • Dot Files
  • DS_Store
  • ._*
  • shell script
  • bash
  • AppleScript
  • terminal
  • unix
  • workflow
  • productivity

  Summary of Comments ( 18 )
  https://news.ycombinator.com/item?id=42987848

  Verbose tl;dr

  Commenters on Hacker News largely appreciated the simplicity and directness of the provided AppleScript solution for removing macOS-specific files from external drives upon ejection. Some highlighted the potential for data loss if used carelessly, especially with networked drives or if the script were modified to delete different files. Others offered alternative solutions, including using dot_clean, incorporating the script into a Hazel rule, or employing a shell script with find. The discussion also touched upon the annoyance factor of these files on other operating systems and the historical reasons for their existence, with some suggesting that their prevalence has diminished. A few commenters mentioned more robust solutions for syncing and backing up, which would obviate the need for such a script altogether.

  The Hacker News post "Automating the cleaning of macOS-specific ( ._ and .DS_Store) files on Eject" generated several comments discussing the author's approach and alternative solutions for managing macOS-specific files on external drives.

  One commenter questioned the necessity of the script, pointing out that .DS_Store files are generally hidden and don't cause issues for most users. They also mentioned that these files serve a purpose for macOS systems and deleting them might have unintended consequences. This commenter suggested educating Windows users about hiding system files instead of automatically deleting them.

  Another commenter highlighted the potential for data loss if the script were to malfunction, emphasizing the importance of robust error handling and thorough testing, particularly when dealing with file system operations. They proposed a more cautious approach involving moving the files to a temporary trash directory instead of immediately deleting them.

  Building on this cautionary theme, another user recounted a personal experience of data loss due to a similar automated cleanup script, reinforcing the risks associated with such solutions.

  One commenter offered an alternative using dotfiles, a common way to manage system configurations, suggesting that the script could be integrated into a user's dotfiles repository for better version control and portability.

  Another user suggested a different technical approach, recommending the use of a shell script triggered by the eject command itself, rather than relying on external tools or applications. They outlined a basic shell command structure for accomplishing this.

  Some users discussed the broader issue of cross-platform file management and the challenges posed by operating system-specific files. One commenter noted that similar issues arise with Windows-specific files like Thumbs.db and advocated for greater awareness and tolerance of these files across different operating systems.

  Finally, several comments focused on the technical details of the script itself, discussing the use of specific commands and suggesting improvements to its logic and error handling. One user questioned the efficiency of the script's find command and suggested an alternative approach using locate. Another user pointed out a potential bug in the script's handling of spaces in filenames.

  In summary, the comments section offered a mix of perspectives, including questioning the need for the script, expressing concerns about data loss, suggesting alternative solutions, and delving into the technical specifics of the script's implementation. The comments highlighted the complexities and potential pitfalls of automated file system manipulation and emphasized the importance of caution and thorough testing.

• Find the oldest line in your repo

  permalink

  Posted: 2025-01-27 02:51:42

  Verbose tl;dr

  Milo Fultz's blog post details a method for finding the oldest lines of code in a Git repository. The approach leverages git blame combined with awk and sort to extract commit dates and line numbers. By sorting the output based on these dates, the script identifies and displays the oldest surviving lines, effectively pinpointing code that has remained unchanged since its initial introduction. This technique can be useful for understanding the evolution of a codebase, identifying potential legacy code, or simply satisfying curiosity about a project's history.

  Milo Fultz's blog post, "Find the oldest line in your repo," explores the fascinating, and potentially useful, task of identifying the most ancient lines of code within a given Git repository. The post begins by acknowledging the inherent curiosity driving this endeavor – a desire to unearth the foundational pieces of a project and understand its evolution.

  Fultz then dives into the technical implementation of this archaeological dig through code history. He meticulously details the use of the git blame command, a powerful tool for annotating each line of a file with information about its last modification, including the author, commit hash, and timestamp. However, simply running git blame isn't enough to pinpoint the oldest lines, as code often moves and changes over time.

  To overcome this challenge, Fultz introduces a more sophisticated approach using git log -L. This command allows tracking the history of specific lines of code, even across file renames and moves. He demonstrates how to combine git log -L with --format=%H to extract the commit hashes associated with each line's history.

  Next, the post explains how to leverage these commit hashes to determine the age of each line. By using git show --pretty=format:%at <commit_hash>, one can retrieve the author date (the time the commit was created) as a Unix timestamp. This allows for numerical comparison and identification of the oldest timestamps, and thus, the oldest lines.

  Fultz provides a clear and concise Bash script that automates this entire process. The script iterates through each line of a specified file, utilizes git log -L and git show to extract and compare timestamps, and ultimately outputs the line number and content of the oldest line(s) found.

  The post concludes by highlighting the practical applications of this technique. Finding the oldest code can be valuable for understanding legacy code, identifying potential technical debt, and perhaps even unearthing interesting historical anecdotes about a project's development. Fultz emphasizes the power and flexibility of Git for delving into a project's past and gaining insights into its evolution.

  • git
  • version control
  • repository
  • code history
  • code age
  • oldest code
  • Software Development
  • Command Line
  • bash
  • shell script
  • git blame
  • git log

  Summary of Comments ( 22 )
  https://news.ycombinator.com/item?id=42836900

  Verbose tl;dr

  Hacker News users discussed various methods and tools for finding the oldest lines of code in a repository, expanding on the article's git blame approach. Several commenters suggested using git log -L for more precise tracking of specific lines or functions, highlighting its ability to handle code moves and rewrites. The practicality of such analysis was debated, with some arguing its usefulness for understanding legacy code and identifying potential refactoring targets, while others questioned its value beyond curiosity. Alternatives like git-quick-stats and commercial tools like CodeScene were also mentioned for broader code history analysis, including visualizing code churn and developer contributions over time. The potential pitfalls of relying solely on line age were also brought up, emphasizing the importance of considering code quality and functionality regardless of its age.

  The Hacker News post "Find the oldest line in your repo" (https://news.ycombinator.com/item?id=42836900) has a moderate number of comments, sparking a discussion around the utility and implementation of finding the oldest lines of code in a repository.

  Several commenters discuss the practical value of such an endeavor. Some suggest it could be a useful tool for identifying legacy code, potential technical debt, or areas ripe for refactoring. One commenter points out that knowing the age of code can help prioritize updates and modernizations, focusing efforts on the most ancient and potentially problematic sections. Another user highlights the potential for uncovering interesting historical insights within a project by examining the oldest surviving lines.

  However, others express skepticism about the inherent usefulness of this exercise. They argue that simply knowing the age of a line of code doesn't necessarily correlate with its quality or relevance. A line of code could be very old yet perfectly functional and well-maintained, while a newer line could be poorly written and buggy. These commenters suggest that other metrics, like code complexity or frequency of modification, might be more informative indicators of areas needing attention.

  The discussion also delves into the technical aspects of implementing this functionality. Commenters mention various tools and techniques, including using git blame or similar version control features to track the history of individual lines. One commenter suggests scripting a solution using git log -L to pinpoint the origin of specific lines. Another points out the potential performance challenges of analyzing very large repositories and suggests strategies for optimization, such as focusing on specific files or directories.

  One thread of the conversation revolves around the interpretation of "oldest." Some commenters interpret this as the earliest committed line that survives in the current version of the code, while others consider it to be the line with the earliest initial commit date, regardless of subsequent modifications. This nuance leads to a discussion of how to differentiate between these two interpretations and the potential implications for analyzing code evolution.

  Finally, some commenters offer alternative perspectives on code analysis, suggesting that focusing on functionality and maintainability is more important than simply the age of the code. They propose using tools that analyze code complexity, test coverage, and other factors to identify areas for improvement.