Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

A brief history of web browsers

By: hoakley
28 June 2025 at 15:00

Although taken for granted now, Apple didn’t release the first version of Safari until January 2003. Before that was a succession of interesting experiments to try. Those started with Netscape Navigator in 1994, which lasted until 2007, although by then it was little used on Macs.

Netscape is seen here in 2000, following my successful purchase of downloadable versions of Conflict Catcher and Suitcase from Casady & Greene’s online store.

Two years later, and I’m browsing Amazon’s listing of my never-published book that was slated for 31 March the following year. I’m so glad I never pre-ordered it.

Netscape had been at the front of browser development, leading with on-the-fly page display, cookies and JavaScript. But in 1996, it was challenged by Microsoft’s Internet Explorer, and Apple’s more innovative Cyberdog. The latter was sadly abandoned the following year, leaving the way clear for Apple to replace the bundled Netscape with Internet Exploder, as it quickly became nicknamed.

This is Microsoft Internet Explorer in 2001, providing the front end to Mac OS X Server through Webmin.

Cookie settings in Explorer were highly detailed in 2005.

Many of us abandoned Internet Explorer for alternatives such as Camino. That had originated within Netscape as Chimera in 2002, based on its Gecko layout engine, with a native Mac OS X front end. The following year it was rebranded as Camino, and amazingly lasted until 2012.

There were other competitors, such as Omni Group’s OmniWeb, which had been developed for NeXTSTEP since 1995, then moved to Mac OS X until 2012.

This is OmniWeb in 2007, showing the different browsers it could identify itself as, including a single version of Safari 1.0.

In January 2003, Apple launched the first beta-release of its own browser, Safari, and bundled it in Mac OS X 10.3 Panther when it was released that October. Since then Safari has been a regular fixture in successive versions of Mac OS X, OS X, and macOS. For several years, it was the only browser on iOS and iPadOS.

This is Safari 1 showing the front page for Apple’s developer site in 2004, complete with the offer to download Xcode version 1.5 with dead code stripping as a new feature. That year, Mozilla Firefox was released as an alternative, and has continued to support Macs ever since.

Mac OS X 10.4 Tiger came with Safari as the only bundled browser when it was released in April 2005, although it took Safari 2.0.4 in early 2006 before it was stable.

Page loading was slow in 2005, when Apple’s front page took a total of over 16 seconds to load fully, but that only used 6.8 MB of memory. By contrast, today Apple’s front page only takes a couple of seconds but requires over 200 MB.

There were times when the only way ahead with these early versions of Safari was to completely reset it, emptying its cache, and even removing all passwords and AutoFill text. This is Safari 2 in 2006.

Prominent among the plugins in 2006 was the dreaded Shockwave Flash, which had only recently been taken over by Adobe when it acquired Macromedia the previous year. Details of plugins are here being displayed on an internal web page within Safari 2.

Safari 3, bundled in Mac OS X 10.5 Leopard in October 2007, brought the claim that it was then the fastest browser, but it was troubled by bugs and security problems at first.

Safari 3 had already grown extensive preferences, covering the use of plugins, Java, JavaScript and cookies, seen here in 2007.

Its successor, Safari 4, followed in the summer of 2009, ready for Mac OS X 10.6 Snow Leopard, with further performance improvements, particularly in its JavaScript engine.

By 2009, Safari 4 was able to warn the user if it was about to visit a site blacklisted by the Google Safe Browsing Service. At least when that service was available. That year also saw Preview and Beta releases of Google Chrome, now Safari’s most serious competitor on Apple’s hardware.

Safari 5 was released a year later, in 2010, and was bundled in Mac OS X 10.7 Lion in 2011. This brought Reader mode and opened the door to third-party extensions.

Safari’s hidden Debug menu provided a collection of tools for web developers, and more recently has become the even more extensive Develop menu.

By the release of macOS 10.12 Sierra in 2016, Safari had reached version 10.

By 2016, close control over Adobe Flash Player had become critical, as a result of its frequent exploits, although it remained highly popular with content developers before Adobe finally killed it at the end of 2020.

Since 2021, with the release of macOS 12 Monterey, Safari 15 and its successors have been able to perform on-the-fly translation, as demonstrated here.

Safari is now the bundled browser in macOS, iOS, iPadOS and visionOS, and this year is set to leap in version number from 18 to 26 with the arrival of Tahoe and its sister OSes. It has been a long and sometimes troubled journey over those 22 years, and despite strong competition from Google Chrome and Chromium-based browsers, it remains the browser of first choice for a great many using Apple’s hardware products. I hope my screenshots have brought back more happy memories than traumatic moments.

Reference

Wikipedia.

A brief history of rebuilding and repairing

By: hoakley
14 June 2025 at 15:00

A cynic might summarise the history of Mac OS in four eras:

  1. rebuilding the Desktop (Classic Mac OS)
  2. repairing system permissions (Mac OS X to OS X 10.10)
  3. resetting Home permissions (OS X 10.11 to macOS 10.15)
  4. cursing privacy protection (macOS 11 onwards).

There is slight overlap between the last two, in macOS 10.14 and 10.15.

Rebuilding the Desktop

Classic Mac OS built its Desktop illusion using hidden databases that associated types of document with icons set by the apps that created them. This was based on two four-character codes in every file to specify the file’s type and creator. Periodically, those databases became damaged and this association stopped working, with the result that all documents were displayed with the same generic icon.

desktopos91

Rebuilding those Desktop databases was initiated by restarting the Mac while holding the Command and Option keys until the dialog was shown. Mac OS then checked through all installed apps to reconstruct their associations with document types.

desktopos95

This had to be repeated for each volume in turn as it was mounted by Mac OS. If there wasn’t sufficient free space on a volume, the process failed. The price of some utilities like TechTool Pro was often justified by the tools they provided for assisting in this process.

desktopos96

Mac OS X ended that reliance on Desktop databases, leaving this to die with Classic Mac OS.

Repairing system permissions

Since its first beta-release, Mac OS X suffered from ill-defined and pervasive problems thought to result from corruption of files used by the system. Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, those generally resulted from files within the system acquiring incorrect permissions. Various reasons were proposed for this, including installer scripts that overstepped their bounds.

To address this, Disk Utility had a feature whereby it could check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in older versions of Mac OS X and OS X, and was an important feature in Disk Utility.

Repairing permissions is no longer the panacea that it once was, but is part of checking general disk health.

Although chiefly intended to provide better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files protected by SIP.

Resetting Home permissions

RepairPermissions

When macOS 10.12 Sierra was released, a different problem appeared, in which permissions apparently became set incorrectly not in system files generally, but in the user’s Home folder, and specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that cfprefsd took on the management of those preference files.

At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:

  • changes to preference settings, particularly those for System Preferences, do not ‘stick’;
  • changes made to the Dock do not ‘stick’;
  • you are asked to authenticate when trying to move or alter some folders in your Home folder;
  • when trying to save, you are told that the file is locked, or that you don’t have permission;
  • Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
  • alerts appear warning that the startup disk has no more space available for app memory;
  • Safari or SafariDAVClient use large amounts of resources (memory);
  • the Mac runs very slowly;
  • iTunes cannot sync a device;
  • there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.

Most if not all of those could be attributable to problems arising from bugs in cfprefsd.

Apple later changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, in June 2020 when Big Sur was in beta, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.

Cursing privacy protection

Prior to macOS 10.14 Mojave, privacy protection had been limited and largely unobtrusive. We then began to discover that our favourite apps were being locked out of accessing files in many of our working folders.

Thus the era of adding apps to the Full Disk Access list started, and we came to curse the blessing of privacy protection.

Even better, Apple later added extended attributes that could prevent apps perfectly capable of editing documents from being able to save them just when we needed that most. And protected the extended attribute using SIP.

docprivacy06

Maybe rebuilding the Desktop databases every couple of months wasn’t so bad after all?

A brief history of local search

By: hoakley
7 June 2025 at 15:00

Spotlight, the current search feature in macOS, does far more than find locally stored files, but in this brief history I focus on that function, and how it has evolved as Macs have come to keep increasingly large numbers of files.

Until early Macs had enough storage to make this worthwhile, there seemed little need. Although in 1994 there were precious few Macs with hard disks as large as 1 GB, networks could provide considerably more. That year Apple offered its first product in AppleSearch, based on a client-server system running over AppleShare networks, and in its Workgroup Servers in particular. This was a pioneering product that was soon accompanied by a local app, Find File, written by Bill Monk and introduced in System 7.5 that September.

Sherlock

The next step was to implement a similar architecture to AppleSearch on each Mac, with a service that maintained indexes of file metadata and contents, and a client that passed queries to it. This became Sherlock, first released in Mac OS 8.5 in 1998. As access to the web grew, this came to encompass remote search through plug-ins that worked with web search engines.

Those were expanded in Sherlock 2, part of Mac OS 9.0 from 1999 and shown above, and version 3 that came in Mac OS X 10.2 Jaguar in 2002. The latter brought one of the more unseemly conflicts in Apple’s history, when developers at Karelia claimed Sherlock 3 had plagiarised its own product, Watson, which in turn had been modelled on Sherlock. Apple denied that, but the phrase being Sherlocked has passed into the language as a result.

Spotlight

Sherlock remained popular with the introduction of Mac OS X, but was never ported to run native on Intel processors. Instead, Apple replaced it with Spotlight in Mac OS X 10.4 Tiger, in April 2005.

Initially, the Spotlight menu command dropped down a search panel as shown here, rather than opening a window as it does now.

A Finder search window, precursor to the modern Find window, is shown in the lower left of this screenshot taken from Tiger in 2006.

Spotlight was improved again in Mac OS 10.5 Leopard, in 2007. This extended its query language, and brought support for networked Macs that were using file sharing.

This shows a rather grander Finder search window from Mac OS X 10.5 Leopard in 2009.

Search attributes available for use in the search window are shown here in OS X 10.9 Mavericks, in 2014.

Spotlight’s last major redesign came in OS X 10.10 Yosemite, in 2014, when web and local search were merged into Global Spotlight, the search window that opens using the Spotlight icon at the right end of the menu bar. With Global Spotlight came Spotlight (then Siri from macOS Sierra) Suggestions, and they have been accompanied by remote data collection designed to preserve the relative anonymity of the user.

This Finder window in OS X 10.10 Yosemite, in 2015, shows a more complex search in progress.

spotlighticloud

This shows a search in Global Spotlight in macOS 10.12 Sierra, in 2017.

searchkey24

Local Search in the Finder’s Find window can now use a wide variety of attributes, some of which are shown here, in macOS 10.13 High Sierra, in 2018. Below are search bars for several different classes of metadata.

searchkey25

Over the years, Spotlight’s features have become more divided, in part to safeguard privacy, and to deliver similar features from databases. Core Spotlight now provides search features within apps such as Mail and Notes, where local searches lack access.

spotlightsteps1

Spotlight’s indexes are located at the root level of each indexed volume, in the hidden .Spotlight-V100 folder. Those are maintained by mdworker processes relying on mdimporter plugins to provide tailored access for different file types. If an mdimporter fails to provide content data on some or all of the file types it supports, those are missing from that volume’s indexes, and Spotlight search will be unsuccessful. This happened most probably in macOS Catalina 10.15.6, breaking the indexing of content from Rich Text files. That wasn’t fixed until macOS Big Sur 11.3 in April 2021.

Over the last few years, macOS has gained the ability to perform optical character recognition using Live Text, and to analyse and classify images. Text and metadata retrieved by the various services responsible are now included in Spotlight’s indexes. From macOS 13 Ventura in 2022, those services can take prolonged periods working through images and file types like PDF that include images they can process to generate additional content and metadata for indexing.

Those with large collections of eligible files have noticed sustained workloads as a result. Fortunately for those with Apple silicon Macs, those services, like Spotlight’s indexing, run almost exclusively on their Mac’s E cores, so have little or no effect on its ability to run apps. For those with Intel processors, though, this may continue to be troubling.

In less than 30 years, searching Macs has progressed from the basic Find File to Spotlight finding search terms in text recognised in photos, in almost complete silence. Even Spotlight’s 20th birthday passed just over a month ago, on 29 April, without so much as an acknowledgment of its impact.

A brief history of Mac OS version numbers

By: hoakley
31 May 2025 at 15:00

With strong rumours that Apple intends changing its version numbering system for the next major release of macOS and its other operating systems, it’s a good time to see how we got to macOS 15.

Early Classic Mac OS

The first version of Classic Mac OS released with the original Macintosh 128K naturally came with System 1.0 and Finder 1.0. Within a few months, version numbering was already becoming confusing, when the successor System Software 0.1 had apparently started at 0.0, but the System itself had reached 1.1. This worsened when System Software 1.0 was released two years later, and came with System 3.1 and Finder 5.2.

Apple then adopted its first triplet numbering scheme that resembled modern Semantic Versioning in System 6.0 of June 1988. Over the following three years that worked its way steadily up to version 6.0.8, then handed over to System 7 on 13 May 1991 without any minor versions being released.

System 7

The first full use of the triplet numbering scheme came with System 7. That had four minor versions, 7.0, 7.1, 7.5 and 7.6, with each having patch releases such as 7.0.1 in between. This scheme followed the rules:

  • the first number gives the major version;
  • the second number gives the minor version that should remain backward-compatible in its changes;
  • the third number gives the patch version denoting backward-compatible bug fixes.

It was then that Apple started to release special versions of Mac OS to support new models, for example 7.1P5 for Performa models, complicating the numbering. This was even worse with System 7.1.2, which was only supplied with some early Power Macs and a few 68K Quadra models. That was accompanied by System 7.1.2P, a special version for models released around the time that Apple also released System 7.5, in September 1994.

System 7.5 brought a different numbering scheme to deal with exceptions. For example:

  • System 7.5.3 Revision 2 followed 7.5.3 without any Revision 1, and made various improvements;
  • System 7.5.3 Revisions 2.1 and 2.2 were released on the same day to address problems with Revision 2 on different models;
  • System 7.5.4 was never released at all, and the next release was 7.5.5.

Fortunately, the remaining versions of Classic Mac OS were conventional in their numbering, until the last in Mac OS 9.2.2 in December 2001.

Mac OS X

The public beta of Mac OS X introduced build numbers to supplement their triplet version numbering. At this time, the build number was based broadly on three components:

  • the first number or build train gives the major version, starting from 4 for 10.0, as this includes NeXTSTEP up to version 3;
  • the letter gives the minor version number, starting from A, which can also be bumped for hardware-specific builds, so may not match the triplet minor version number;
  • the remaining number is the sequential build number within that minor version, usually incremented daily. That’s normally three digits, but an additional digit can be prefixed to indicate specific hardware platforms.

Triplet versions and build numbers were surprisingly well behaved until 2010, although separate build numbers were used during the transition from PowerPC to Intel architecture in Mac OS X 10.4 Tiger.

The first signs of complications came with Mac OS X 10.6.3, in March-April 2010, which came in three different builds and a v1.1, and 10.6.8 also had a v1.1 released a month after the original update. Mac OS X 10.7 Lion set a trend for a final Supplemental Update to 10.7.5, and frequent Security and Supplemental Updates became the rule by 2018, with macOS 10.12 Sierra and its successors.

By 2019, these updates had become uncontrollable. macOS 10.14 Mojave, for example, had three Supplemental Updates in the two months after its final release, named as 10.14.6 Supplemental Update, 10.14.6 Supplemental Update (a second time), and 10.14.6 Supplemental Update 2 (really 3).

macOS 11

The first version of macOS to support Apple silicon Macs, macOS 11 Big Sur, had been generally expected as macOS 10.16, but shortly before its announcement at WWDC in June 2020 the decision was made for it to become macOS 11, incrementing the major version number for the first time in almost 20 years. As that reset the minor version number from 15 to 0, there was the potential for chaos, as many scripts and much code had come to ignore the major version number, and to rely on the minor version to determine which release was running.

To cater for this, when those checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 10.16. Apps ported to Xcode 12 used the 11.0 SDK; when they checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 11.0. Those who relied on command tools were provided with a workaround, as
sw_vers -productVersion
returned 10.16 when running in Big Sur on an Intel Mac, but 11.0 on an Apple Silicon Mac.

This enabled Apple to return to a triplet scheme without the complications of Supplemental Updates or other vagaries. Each year’s major version of macOS has thus been x.0, with scheduled minor versions numbered from x.1 to x.5 or x.6, and intermediate patch releases (usually security updates) from x.x.1 upwards. At the end of its year as the current release of macOS, x.6 marked the start of its first year of security-only support, and x.7 for the second and final year. The exception to this has been Sonoma, which started its first year of security-only support with version 14.7, so its security updates have coincided in their minor and patch numbers with the older Ventura.

The only complication to this much clearer system was introduced in Ventura with Rapid Security Responses (RSRs). Those didn’t change the triplet version, as macOS proper remained unchanged, but added a letter to form, for example, macOS 13.4.1 (c). That proved clumsy, and when reflected in a resulting Safari version number it broke a lot of major websites that were unable to identify the browser version correctly. Since RSRs have fallen out of favour, this proved to be a passing phase.

When I wrote about the unexpected change in version numbering brought in Big Sur, I claimed that “no matter what Apple may eventually settle on, I shouldn’t have to change that again for many years.” I’m not sure that five counts as many, but here we go again.

References

Semantic Versions, SemVer
Apple package version numbering
Robservatory Mac OS X versions and release dates
System updates, including security data etc., since 2016

A brief history of text on the Mac

By: hoakley
19 April 2025 at 15:00

When the Mac 128K was launched, the computing world was quite happy working with text composed using single-byte characters, and the full 256 characters of Extended ASCII seemed quite sufficient. In those days, encoding text for each language was based on its code page, a different set of 256 characters according to that language’s needs and conventions.

The Mac’s initial version of Extended ASCII became its standard Mac OS Roman encoding by System 6.0.4 in 1989. Since then it has been modified to add support for the euro currency symbol in 1998, and is still supported in macOS. Other code pages for single-byte character encoding extended to Mac OS Icelandic, for example, which formed the basis of Macintosh Latin used by the popular Kermit file-transfer software.

Many languages can’t be encoded in such small character sets, and required 2-byte encodings instead. Dealing with these complexities and support for different writing directions became the task of the Script Manager, introduced in System 4.1 in 1987.

Another fundamental concept in Mac OS has been that text isn’t just a character set, but has to be drawn on the display with other graphics content. Text handling thus became integrated with its rendering and features such as word breaking and ligatures. Support for handling text using mixed scripts came in two optional extensions: WorldScript I for single-byte encodings, and WorldScript II for 2-byte encodings such as Chinese, Japanese and Korean.

There were two more mundane complications for the Classic Mac OS user: line termination, and string handling in code.

While MS-DOS and PCs used the combination of carriage return and line feed characters (\r\n) to terminate lines, Classic Mac OS used carriage return (\r) alone, then Mac OS X followed the Unix convention of using line feed (\n) alone. Although the better text editors supported each of those, and would convert text files between them, that became tedious.

Much application development for Classic Mac OS was performed in Apple’s Macintosh Programmer’s Workshop (MPW) using the extended implementation of Pascal known as Object Pascal. This had adopted UCSD Pascal string format, in which the first byte(s) in its native strings contained the length of the string in bytes, rather than its first character. This was all the more confusing when combining projects with C, whose native string format didn’t preface its characters with length, but terminated every string with a null byte.

In 1985, while working on KanjiTalk, the heart of the Mac’s Japanese localisation, Mark Davis and Ken Krugler developed ideas that eventually led to Unicode. When Davis hired Lee Collins to join him at Apple from Xerox, they developed their proposals further, and in 1987 Apple was one of the founders of the Unicode Consortium. The following year, Apple decided to build Unicode support into TrueType, the new font standard it released in System 7 in 1991.

In 1998 System 8.5 integrated support for Unicode text, in Apple Type Services for Unicode Imaging, ATSUI, which was still supported until 2022, and has finally been removed altogether in macOS 14 Sonoma the following year. Initial support for Unicode included UTF-16 encoding to the Unicode Standard version 2.1. Conversion between text encodings was provided by the Text Encoding Conversion Manager.

Core Text superseded ATSUI in Mac OS X 10.5 Leopard in 2007, and is part of the Cocoa text system inherited from NeXTSTEP.

One unexpected new feature of Unicode was the LastResort, the symbol shown for a code point that doesn’t exist yet, and the product of garbled text, seen here in 2007.

Even in familiar languages like Greek, Unicode offers exotics such as GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI, whatever that might be used for.

However, Unicode has brought its own problems, among them its acceptance of multiple code points (character encodings) for visually identical characters. In normal text use this can impede searching, but becomes more critical with the naming of files and directories.

The letter Å can be represented in UTF-8 as either C3 85 (Form C) or 41 CC 8A (Form D). Search for the word Ångström using Form C, and you won’t find the same word using Form D instead. A file system that allows both forms to appear independently in file and directory names appears to the user to allow items with duplicate names, and that poses further problems for search.

In Apple’s Macintosh Extended (HFS+) file system, Unicode normalisation is used to map characters to Unicode Form D, but when Apple developed APFS it intended to leave any normalisation to apps. Early releases of APFS thus didn’t perform normalisation, resulting in many problems for app developers and users. This was rectified by incorporating a normalisation layer into macOS to return to the relative sanity of Form D.

apfelstrudel10

apfsvol08

It would perhaps be better to close without mentioning the annual additions to emoji supported in Unicode, as announced prominently in macOS updates. It has been a long and sometimes arduous journey from Extended ASCII to the 😁 of 🤷.

Apple Inside Macintosh: Text (1993)
Pascal string types in the Free Pascal and Lazarus Wiki
Unicode – the beginnings, Mark Davis and others
Apple Core Text Programming Guide (2007-2014)
Apple Core Text, current documentation

如何在Mac OS X上结束一个进程?

By: jane9309
24 March 2016 at 21:00

刚才看论文做笔记时Evernote突然停止响应了,本打算用Activity Monitor强制关闭,转念一想,不如学下如何用terminal强制关闭程序吧!正好有人对kill的一些写法有疑问,放上来分享一下。

1. 活动监视器(Activity Monitor)

不论是Windows还是Mac OS X,一定有任务管理器或活动监视器可以查看进程。想要强制终止一个进程很简单,只要找到想要终止的程序,然后点击左上角的八边形带×按钮即可。
Screen Shot 2016-03-24 at 20.01.48

2. Mac OS X 终端(Terminal)

在Terminal上输入命令来终止程序也很简单。分两步走:1. 拿到想要关闭的进程的ID(即PID);2. 命令此ID的进程关闭。下面展示下操作过程:

假设我想把Evernote强制关闭,首先打开Terminal,输入:
ps -A | grep Evernote
ps是“process status”的缩写,意思是“进程状态”,“ps -A”会列出所有当前正在运行的程序,如果此时直接回车,那么你会在terminal上看到一长串的进程,想要找到Evernote的PID不是很方便……
Screen Shot 2016-03-24 at 20.22.03
为了更方便找到Evernote所对应的PID,我们要对这些让人看得头晕的输出进行小小的处理。“|”是个pipeline,会把当前输出的文本(也就是上头一大串进程)输入到右边的命令中。“grep”你可以把它理解成“抓取”,它会从前面输入的文本中抓出带有想要搜索的文字的所有行。看下图,是不是很简洁?马上就知道Evernote的PID是945了(另一个是EvernoteHelper,不用理会)。
Screen Shot 2016-03-24 at 20.29.10
接下来进入正题——杀死进程!输入:
kill 945
然后……就结束了……杀进程很简单吧?
来我们复习一遍:
找PID: ps -A|grep [进程名]
杀进程:kill [PID]
======
补充:
  1. 请勿随意使用强制结束进程,这是在程序无法响应时才使用的杀招,如果文件没有保存,强制结束进程可能会让你丢失未保存内容。
  2. kill -9 [PID]”也能结束进程,9其实是SIGKILL对应的号码,自然也可以用“kill -SIGKILL [PID]”来结束。大家可以输入“kill -l”查看各种对应代码。
Screen Shot 2016-03-24 at 20.44.18

❌
❌